Forum Miłośników Symulatorów Lotniczych
Zaplecze => Software & Hardware => Sprzęt wykonany samodzielnie => Wątek zaczęty przez: mickey81 w Maja 13, 2009, 07:57:46
-
Pozwoliłem sobie założyć nowy wątek dla pit-builderów, żeby nie zaśmiecać forum. Moglibyśmy tu umieszczać schematy sterowań panelami, dyskutować na temat programowania itp itd
-
Na początek parę uwag.Nasze forum ma charakter ogólny,dlatego sprawy związane z budową kokpitów są marginalne.Są fora wyspecjalizowane np.
http://www.vatsim.home.pl/viewforum.php?f=68 oraz viperpits.W tym ostatnim biorę udział.Ponieważ należę do tego forum od paru lat i mam do niego sentyment postanowiłem kontynuować temat budowy paneli właśnie na naszym forum,chociaż biorę także udział w innych.
Z tego co wiem to jest paru kolegów,którzy myślą o budowie paneli lub już je realizują.W tym roku dołączyli nowi także zainteresowani tym tematem.
Moje plany to dokończenie mojego minikokpitu dla F16 a następnie rozpoczęcie zabawy z FSX.Nie wiem czy będzie to możliwe tzn.pogodzenie symulatora FalconAF oraz FSX.Sprawa wydaje się trywialna ale tylko pozornie.Dotyczy to PC.Falcon jest niestety starym symulatorem i jeśli myślimy o zabawie z MFD oraz FalconGauges to musimy zastosować odpowiednie karty graficzne oraz sterowniki (raczej starsze oraz jednolite dla wszystkich kart) oczywiście WinXP.
Jeśli chodzi o FSX to odwrotnie dobre karty oraz vista.Jest też ograniczenie dotyczące samolotów a konkretnie możliwości ich sterowania.Some1 wspominał o samolotach będących w pakiecie FSX.
Są to moje problemy.Jeśli ktoś decyduje się tylko na Falcona lub FS lub FSX to nie będzie miał tych problemów.
Możliwości mojego PC już się wyczerpały i muszę kupić nowy.Ponieważ myślę o MFD i cyfrowym CP dla Falcona to muszę kupić nowy PC z 2 kartami graficznymi.
Duża część kolegów na forum zachwyca się FSX-em,dlatego myślę także o tym symulatorze.W mojej skromnej praktyce z Falconem odzwyczaiłem się od klawiatury,dlatego myślę o budowie paneli dla FSX.
Ponieważ nie mam zielonego pojęcia o FSX to liczę na opinie kolegów z forum.Nasuwa się parę pytań:
1-czy jest sens budowanie paneli dla tego symulatora
2-jeśli tak to jakie panele czy dla konkretnego samolotu czy jakieś uniwersalne jeśli jest to możliwe.
Są to podstawowe pytania.Jeśli odpowiedź będzie pozytywna to można myśleć o realizacji czyli na początek jakie oprogramowanie a później hardware.Tyle moich ogólnych uwag.
-
1. Wielu ludzi je robi (choć widziałem więcej relacji dotyczących FS9), więc chyba "sens" ;) jest: http://www.mycockpit.org/
2. To zależy, jakimi samolotami chcesz latać - panele GA można zrobić całkiem uniwersalne, jednak większe samoloty różnią sie już dość znacznie i gdyby robić uniwersalne panele, trzeba by niestety parokrotnie zrezygnować z realizmu odwzorowania jednej maszyny na rzecz uniwersalności.
-
Ja od siebie powiem tylko, że hasłem FSa jest 'As real as it gets', więc skoro tak, to najlepiej jak najmniej myszy i klawiatury przy sterowaniu :002: , czyli budowa kokpitu - tak! Miałem podobny dylemat co kolega Vitio, czy pit robić pod Falcona czy pod FSa. Idealnym rozwiązaniem byłby kokpit uniwersalny, jednakże nie jest to takie proste. Nie wszystkie systemy z F-16 znajdują odzwierciedlenie w samolotach cywilnych, a tych jest jednak najwięcej w FS. Oprogramowanie sterowania do dodatków innych firm nastręcza wielu problemów i jest czasochłonne (patrz Aerosoft F-16). Dlatego złotym środkiem według mnie jest budowa kokpitu o układzie zbliżonym do F-16 w sensie ergonomii (bo ta jest niezaprzeczalnie doskonała w tym myśliwcu), ale zawierającego sterowanie systemami samolotów pod FSXa. Oczywiście jest mnóstwo paneli funkcjonujących identycznie, pompa paliwa, rozrusznik, akumulator etc, ale np MFD można wykorzystać do obsługi garminowskiego Glasscockpitu. ICP może służyć do komunikacji z ATC. Możliwości jest sporo i myślę, że warto podjąć wysiłek. Tym bardziej, że na tym forum jest kilku naprawdę świetnych specjalistów w dziedzinie elektroniki. Wspólnymi siłami udało się zmusić mjoy do działania, FSLCD również, Vito walczy z OpenCockpits. To są osiągnięcia, które motywują do pracy. Z FSXem nie ma większych trudności, da się go oswoić. Można wyświetlić sporo części kokpitu w oknach, które z kolei wyświetlone na dodatkowym monitorze, zabudowanym w jakąś konsoletę, znakomicie ułatwiają zabawę. Dla mnie osobiście procedura startu nawet zimną Cessną jest ogromną frajdą, gdy mogę sobie pstryknąć pompę paliwa, włączyć światła. Nie klikając myszą, ale przełączając przełącznik.
A więc do roboty!
Pozdrawiam
mickey81
-
Idealnym rozwiązaniem byłby kokpit uniwersalny, jednakże nie jest to takie proste.
Pomijając kwestie, które wymieniłeś, już na początku trzeba określić, czy kokpit ma służyć raczej do obsługi samolotów z drążkiem, czy z wolantem. Ta z pozoru niewielka różnica jest istotna - w końcu drążek zazwyczaj obsługuje się prawą ręką (nie liczę tu lewego siedzenia za sterami Airbusów ;)), natomiast wolant lewą, prawą wykorzystując od obsługi m.in przepustnic. Od tego wyboru zależy przecież umiejscowienie dźwigni klap, wajchy podwozia i pozostałych urządzeń używanych w krytycznych stadiach lotu - w końcu odrywanie ręki od sterów jest wtedy niewskazane.
Ciekawym pomysłem byłby kokpit modułowy, dający możliwość przeniesienia pewnych instrumentów z lewej strony na prawą - mam jednak obawy, ze to brzmi fajnie jedynie jako projekt, a realizacja i wykorzystanie nastręczałoby problemów.
-
Jak widać z pierwszych wypowiedzi uniwersalność stoi pod znakiem zapytania.Tak jak wspominałem na viperpits są faceci,którzy używają kokpitu F16 jako F14 w LockOn zmieniając tylko oprogramowanie.Początkowo sądziłem,że będzie można wykorzystać kokpit z Falcona w FSX,ale to jest niemożliwe (mam na myśli mod F16 dla FSX).
Na stronie OpenCockpits sprzedają panele do 737,747,767 oraz 320 czyli można takie panele wykonać wykorzystując ich soft.
Co do mnie to chciałem ułatwić sobie życie i latać na F16 w środowisku FSX.Ponieważ jest to niemożliwe to pozostaje albo wybrać jakąś prostą,ale ciekawą maszynę i zrobić uproszczony kokpit,albo zacząć budować jakieś "uniwersalne" panele.Co o tym sądzicie?
-
Myślę, że to jest właściwy kierunek. Co do wyboru wolant-drążek to chyba sprawa indywidualna, co kto lubi. No chyba, że się nie ma co się lubi ;) W moim przypadku z racji posiadania HOTAS X52 sprawa jest jasna. Zestaw ten dodatkowo ogranicza miejsce w lewej konsolecie. Jeśli go montować pod konstrukcją konsoli, nie ma możliwości instalacji 'domyślnych' paneli do 16-tki. Dlatego byłem zmuszony je przeprojektować. Wynikiem tej operacji są właśnie takie 'uniwersalne' panele, o których wspomniał Vito. Jedyne co mogę jeszcze podpasować to drążek, który można umieścić za przeproszeniem między nogami :P lub jak w F-16 z prawej strony. Druga opcja wydaje mi się lepsza, bo wówczas na środkowej konsolce (tam gdzie ADI) można zamontować panele radiostacji, transpondera itp. Chodzi mi po głowie jeszcze pomysł z wykorzystaniem drugiego monitora. Można by pokusić się o obudowanie monitora od frontu panelem z pleksiglasu z umieszczonymi obok siebie imitacjami MFD w ten sposób, żeby było widać przez nie część monitora. Wtedy, wykorzystując możliwość wyświetlenia różnych wskaźników w osobnych oknach, można by je wyświetlić na tych pseudo-MFD, przy czym przyciski od MFD oprogramować dowolnie mjoyem lub jeśli dobrze pamiętam master-er z Opencockpits. I prosty pit do FSXa byłby gotowy. Częściowo chyba dałoby się go wykorzystać i do innych symulatorów - kwestia oprogramowania przełączników i przycisków, a oprofilować np Falcona, to nie problem. Jak koledzy myślą?
Pozdrawiam
mickey81
-
Ponieważ jest to niemożliwe to pozostaje albo wybrać jakąś prostą,ale ciekawą maszynę i zrobić uproszczony kokpit,albo zacząć budować jakieś "uniwersalne" panele.
Mi bardziej podoba się idea uniwersalnych paneli, nastawionych raczej na samoloty GA - radioodbiorniki oraz większość przełączników powtarza się w niewielkich samolotach śmigłowych (raczej zachodnich),a do tego w większości samolotów dodatkowych te systemy nadal są oparte na defaultowych schematach działania - dzięki temu w sferze programowej nie powinno być z nimi wielkich kłopotów.
Chodzi mi po głowie jeszcze pomysł z wykorzystaniem drugiego monitora. Można by pokusić się o obudowanie monitora od frontu panelem z pleksiglasu z umieszczonymi obok siebie imitacjami MFD w ten sposób, żeby było widać przez nie część monitora.
Są i chyba sie sprawdzają: http://secure.simmarket.com/vr-insight-jetpit.phtml , http://secure.simmarket.com/vr-insight-pro-pit.phtml ;) A'propos dodatkowych monitorów - czy ktoś ma jakieś doświadczenia z programem Touchbuddy (http://touch-buddy.com/forums/index.php)? Niewielki ekranik dotykowy wygląda na bardzo wygodny dodatek, a do tego jak fajnie by się nim obsługiwało FMC ;)
-
Owszem, czytałem o tym, nawet było na forum, ale cena takiego 'dotykowca' zaporowa ok 700-800 PLN. TouchBuddy o ile dobrze pamiętam pracuje także ze zwykłym monitorem, ale według mnie takie użycie mija się z celem. We wszelkiego rodzaju palmtopach ekran LCD ma warstwę dotykową, którą można zdjąć i wymienić. Coś mi się zdaje, że jest też możliwość dołożenia tego na większe ekrany, ale nie daję głowy.
Pozdrawiam
mickey81
Ha! http://www.dotyk.magit.pl/nakladki-dotykowe.html
-
Jak widzę temat budowy paneli (kokpitów) dla FSX na razie nie wzbudził większego zainteresowania.Może jak temat będzie kontynuowany zainteresowanie będzie większe.
Wspomniałem w moich poprzednich wątkach o założeniach,które przyjąłem przy budowie swoich kokpitów.Jednym z założeń jest "sensowny" budżet.Na viperpits można kupić prawie wszystko do F16,ale jest to drogie.Dla pitbuiderów z państw zachodnich ceny nie są zaporowe dla nas już są.Niektórzy pitbuiderzy wykonują krótkie serie niektórych elementów i je oferują innym.Ma to sens,ponieważ zmniejsza koszty.U nas także zastosowaliśmy tę metodę (w skromniejszym wymiarze)przy realizacji MJoya.
Ja myślę o kokpicie lub panelach dla FSX tylko ze względu na zachwalane zalety tego symulatora,ale nie rezygnuję z mojego podstawowego symulatora Falcona.
Muszę kupić nowy PC między innymi dlatego,że chcę zrealizować pełny MFD czyli z wyświetlaniem oraz pełny CP zrealizowany także na LCD.Są to już dosyć duże koszty.
Dobrze,że dyskutujemy o różnych wariantach,ponieważ z tej dyskusji mogą powstać jakieś optymalne założenia dla dalszej realizacji.Dobrze byłoby gdyby do dyskusji dołączył Zajac,który ma już jakieś doświadczenia z FSX.
-
Vito, czy kupowałeś jakieś kity OpenCockpits, czy wszystko wykonywałeś na własną rękę?
-
Dobrze byłoby gdyby do dyskusji dołączył Zajac,który ma już jakieś doświadczenia z FSX.
Witam, bardzo chętnie się przyłącze, ale od razu dodam. że doświadczenie mam raczej z FS2004 nazywanym również FS9. Mam za słabego kompa do FSX-a. Poza tym do FSX-a jest mniej dodatków i większość kokpitów powstało na bazie FS2004. Natomiast samo sterowanie / połączenie z kokpitem / jest bardzo podobne, powstała też wersja fsuipc na FSX-a. Fsuipc / http://www.schiratti.com/dowson.html / to podstawowy, według mnie, program do komunikacji do i od FS-a, za pomocą, którego można komunikować się Flight Simulatorem.
-
Zerknijcie koledzy na to: http://www.andare-ing.com/uploads/Manual_USBLcd_ingles.pdf
Steruje wyświetlaczami LCD przez interfejs USB. Więcej szczegółów pod tym linkiem http://www.opencockpits.com/modules.php?name=Downloads&d_op=viewdownload&cid=49
Wygląda na to, że część projektów Opencockpits nie wymaga do działania płyty matki (Master)
Jeśli się mylę, sprostujcie
Pozdrawiam i lecę do poligrafika :)
mickey81
-
Elektronikę robiłem sam,ale odradzam lepiej kupić kit do montażu.Rozwiązanie Zajca jest proste i tanie w odróżnieniu od OC.Ma ono jednak ograniczone zastosowanie do FS a nie do FSX (może się mylę).
Niektóre karty OC nie wymagają karty master.
Jeśli nie będzie możliwe złożenie nowego PC pod kątem zastosowania Falcona (MFD) oraz FSX to może będę zmuszony do zabawy w FX lub rezygnacji z tego symulatora.
ps
Zapomniałem dodać,że projektowanie kokpitu to zajęcie na kilka miesięcy lub nawet lat.To o czym piszemy to tylko wstępne rozeznanie w temacie.
-
...projektowanie kokpitu to zajęcie na kilka miesięcy lub nawet lat.To o czym piszemy to tylko wstępne rozeznanie w temacie.
Dokładnie, ja od roku się z tym męczę :( Ale nie zrażam się niepowodzeniami, tylko uparcie walczę dalej bogatszy o doświadczenia innych kokpitowców-maniaków :)
Co Koledzy myślą o panelach z anodowanego aluminium? Są czarne ok 3mm grubości grawer biało-szary. Minusem jest brak możliwości podświetlenia od spodu, ale jakość powala na kolana. Myślę poważnie o wykonaniu panelu testowego w tej technice, wybadam koszty.
Gdy tylko będę wiedział więcej, dam znać.
-
Witam
Ostatnio wpadłem na pomysł skonstruowania modułu do radia do FS-a. Ma to być coś w rodzaju multiradia. Potrzebne elementy to
- płytka od jakiegoś gamepada, minimum 12 przycisków / nie opłaca się brać całego mjoy-a 112 przycisków /
- płytka do encoderów / wątek o mjoy-u / i odpowiednie elementy do niej
- fslcd - płytka lub samodzielne podłączenie oraz wyświetlacz 4x16
- przełącznik obrotowy 8x1 pozycyjny
- dwa encodery
- jeden przycisk typu reset
- obudowa typu pulpit
Całość pracowała by pod kontrolą FSUIPC-a / ostatnio przeglądałem manual do niego, i wtedy pomyślałem, że można by coś takiego zbudować /. Przełącznikiem obrotowym przełączamy tryby pracy, a encoderami ustawiamy odpowiednie wartości i jednocześnie odpowiednie dane są wyświetlane na wyświetlaczu LCD, natomiast przełącznik typu reset służy np. do zmiany standby na active, wszystko jest do zaprogramowania za pomocą FSUIPC-a.
Myślę, że takie tryby pracy powinny, się znaleźć oraz czym sterują encodery - boldem i przycisk :
1. COM1 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
2. COM2 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
3. NAV1 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
4. NAV2 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
5. ADF1 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
6. ADF2 / enc1 - częstotliwość przed przecinkiem enc2 - częstotliwość po przecinku reset - zmiana stendby na active
7. XPDR / enc1 w lewo pierwsza liczba +, enc1 w prawo druga liczba +, enc2 w lewo trzecia liczba +, enc2 w prawo czwarta liczba + , reset - zmian standby - mode c
Na wyświetlaczu w zależności od trybu pracy mogą się wyświetlać różne dane potrzebne w danej chwili - oto moja propozycja
(http://img193.imageshack.us/img193/6932/lcdradio.th.jpg) (http://img193.imageshack.us/my.php?image=lcdradio.jpg)
W ciągu paru dni spróbuje to rozrysować - i wtedy napiszę
pozdrawiam
Zając
-
powstała też wersja fsuipc na FSX-a.
Czy wersja dla FSX obsługuje także FS?
Pytam dlatego,że rozpatruję instalację FS2004 na moim starym PC po to aby,rozpocząć testowanie prototypów.Jednocześnie myślę docelowo o FSX.Jeśli jest to niemożliwe to mam podwójny zakup fsuipc dla FS oraz FSX.
Czy sam fsuipc wystarczy do sterowania paneli w FS?
Jeśli myślimy docelowo o większej liczbie LCD to warto pomyśleć o innym interfejsie.
-
Czy wersja dla FSX obsługuje także FS?
Pytam dlatego,że rozpatruję instalację FS2004 na moim starym PC po to aby,rozpocząć testowanie prototypów.Jednocześnie myślę docelowo o FSX.Jeśli jest to niemożliwe to mam podwójny zakup fsuipc dla FS oraz FSX.
Czy sam fsuipc wystarczy do sterowania paneli w FS?
Jeśli myślimy docelowo o większej liczbie LCD to warto pomyśleć o innym interfejsie.
Są dwie wersje, inna dla FS2004 i dla FSX-a i raczej wersja dla FSX-a nie obsłuży FS2004, natomiast większość funkcji mają identyczne.
FSUIPC jest podstawą i większości przypadków wystarczy do obsługi paneli. Dopiero do bardziej złożonych konstrukcji jest potrzebny dodatkowy soft, najczęściej dołączany do sprzętu, który i tak korzysta z FSUIPC-a.
Co do zmiany interfejsu to się zgadzam / wyświetlacze / przy pomocy FSLCD można obsłużyć jedynie dwa wyświetlacze, a poza tym nie każdy ma port LPT w swoim kompie, a na przejściówkach typu USB->LPT nie chce działać.
Zając
-
Ciekawym pomysłem jest wykorzystanie komputera tablet pc jako uniwersalnego panelu sterującego.
Tutaj filmik (http://www.truveo.com/FSX-G1000-Cessna-client-display-on-Tablet-PC/id/396317259).
W tym przypadku wykorzystany został typowy tablet pc bez możliwości wskazywania palcem. W przypadku TX2500 od HP można wykorzystywać rysik jak i palucha, sam korzystam z niego na co dzień.
Nieco ciekawszą inwestycją jest wykorzystanie dużych monitorów lcd z powłoką dotykową, lecz nie mam pojęcia jak wygląda kwestia rozłożenia tych widoków przy użyciu wielu monitorów na jednym komputerze. Z tego co mi się wydaje to na w/w filmiku jest tablet pc wykorzystywany jako oddzielny komputer który jakimś sposobem jest podlinkowany do symulatora na normalnym desktopie.
-
...nie każdy ma port LPT w swoim kompie, a na przejściówkach typu USB->LPT nie chce działać.
Zając
No to lipa :( Czyli w przypadku laptopów Opencockpits?
Mam informacje odnoście anodowanego aluminium. Otóż koszt to 25gr/cm2. Przy większej ilośći np 50szt 18-20gr/cm2. Czyli przykładowy panel podwozia z F-16 o wymiarach około 17x19,5 cm = 330cm2. Licząc po 25gr, wychodzi 82,45 PLN. Sami oceńcie jak wygląda stosunek ceny do jakości. Aha, grubość płytki ok 1mm, dosyć sztywna. Poniżej fotografia przedstawiająca przykładową tabliczkę grawerowaną w anodowanym alu. Płytka w dotyku gładka, jasne, grawerowane miejsca jasno szare, lekko porowate (jak papier ścierny 2000)
(http://lh6.ggpht.com/_UJ6EyH2DD6o/Sg14-3alkVI/AAAAAAAAC_s/-jTDRrwDduE/DSC02579_mini.jpg)
Poprosiłem również o wykonanie próbki inna techniką. Na pleksi naklejona czarna foli i w tej folii grawer laserowy. Wyszło całkiem nieźle. Koszt to ok 1,5zł/min pracy plotera, czyli dużo taniej.
Poniżej płytka podświetlona latarką diodową. Efekt według mnie zupełnie niezły.
(http://lh4.ggpht.com/_UJ6EyH2DD6o/Sg2C6DPaE3I/AAAAAAAAC_4/wNw0IAuMcHY/DSC02583_mini.jpg)
I ostatnia rzecz. Elementy do mojego MFD. Wkrótce przystępuję do montażu.
(http://lh3.ggpht.com/_UJ6EyH2DD6o/Sg2C3PqlFxI/AAAAAAAAC_w/jcVJ8WMQtr0/DSC02585_mini.jpg)
-
FSUIPC jest podstawą i większości przypadków wystarczy do obsługi paneli.
Następne pytanie.Czy panele są połączone z PC przez USB?
Nie znam FSUIPC,ale z tego co przeczytałem to jest to interface programowy łączący FS,FSX z np.oprogramowaniem SIOC OC sterujący ich kartami.
Z tego wynika,że producenci kart,paneli do tego symulatora muszą przewidzieć soft dla FSUIPC po to aby się z nim komunikować.Czy dobrze myślę?
Całość pracowała by pod kontrolą FSUIPC-a
Jak to rozumieć?Fslcd ma swoje oprogramowanie i jest widziane przez FS,enkodery przez MJoy oraz SVMapper są widziane jako klawiatura,pozostają jedynie przyciski.
Czy można gdzieś zdobyć manuale do FSUIPC?
-
Instrukcja do FSUIPC jest dołączona do samego FSUIPC, którego można ściągnąć ze strony Petera Dowsona.
-
Przejrzałem pobieżnie stronę vatsim.Jest tego dużo.Nasuwa się parę uwag.Niektórzy realizują fragmenty kokpitów wykorzystują proste oprogramowanie.Kilku realizuje poważniejsze projekty przy pomocy FSBUS lub innego softu np.z OpenCockpits.Ciekawy jest projekt Nico Kaan http://www.lekseecon.nl
Są to projekty dużych maszyn.Jest wzmianka o Cesnie,ale brak szczegółów http://www.vatsim.home.pl/viewtopic.php?f=68&t=24566
Mam kilka niejasności dotyczy to możliwości sterowania maszyn w FS.
Czy Level-D 767-300 jest płatnym dodatkiem do FS,który umożliwia pełną kontrolę w FS dla maszyny 767?
Czy inne maszyny wchodzące do pakietu FS także można kontrolować tak jak wspomniany powyżej 767?
Jaka jest różnica?
Postanowiłem zbierać informacje na temat budowy kokpitu dla FS,ponieważ FSX jest związany z zakupem nowego PC a to wymaga czasu.Chciałbym rozpocząć od prostej maszyny typu Cesna.
Na stronie OpenCockpits znalazłem program pod nazwą GaugeComposer.Czy ktoś może coś na ten temat powiedzieć?
Ponieważ jest problem z wskaźnikami mechanicznymi to mam zamiar realizować ich graficzne odpowiedniki,dlatego interesuje mnie wspomniany powyżej program.
Znalazłem także na stronie vatsim coś takiego: http://www.komputronik.pl/Akcesoria_USB/Konwertery/Konwerter_USB_1284A_USB__LPT_/pelny,id,2094/
może można to zastosować także do LCD?
-
Znalazłem także na stronie vatsim coś takiego: http://www.komputronik.pl/Akcesoria_USB/Konwertery/Konwerter_USB_1284A_USB__LPT_/pelny,id,2094/
może można to zastosować także do LCD?
Według Zająca niestety nie działa. Ale może to być uzależnione od modelu przejściówki. Mnie z powodzeniem udało się uruchomić poprawnie konwerter USB->COM, ale również USB->LPT, przy czym nie była to chińszczyzna z allegro. W pierwszym przypadku portu COM używałem do komunikacji z modułem GSM centrali alarmowej, w drugim z drukarką. Nie wiem, jaka różnica jest w komunikacji między PC a FSLCD, że nie podobno nie chce to działać. Moim zdaniem, dopóki się nie sprawdzi, niczego nie można być pewnym.
-
Czy Level-D 767-300 jest płatnym dodatkiem do FS,który umożliwia pełną kontrolę w FS dla maszyny 767?
Tak, Level-D to płatny dodatek, symulujący 767-300: http://www.leveldsim.com/sevensix_home.asp
Czy inne maszyny wchodzące do pakietu FS także można kontrolować tak jak wspomniany powyżej 767?
Tak, ale jedynie te oparte na defaultowych systemach. Level-D to chlubny wyjątek wśród dodatków, inne już nie współpracują tak ładnie, gdyż nie można z nich "wyciągnąć" informacji dla kokpitów.
-
Chciałbym rozpocząć od prostej maszyny typu Cessna
Zerknij w ten temat http://www.forum.vatsim.pl/viewtopic.php?f=68&t=25867
Dosyć ładnie zrobiony panelik dla Cessny
-
Przejrzałem projekt Cesny pod tym linkiem.Jest interesujący.Zrobiłem krótki przegląd innych projektów.Odbyłem konsultacje mailową z pitbuiderem A320 i mam już jakieś ogólne pojęcie o kokpitach dla FS (FSX).Wniosek ogólny jest następujący:
-jest to kosztowna zabawa na kilka lat nawet dla prostej maszyny typu Cesna i wymaga dużej wiedzy,
-można realizować fragmenty kokpitu na prostych programach i sterownikach np.MJoy lub sterowanie LCD,tak jak robi to Zajac.
Co do mnie to mam wybór albo kończę swój kokpit tzn.realizuję następny etap lub rozpoczynam budowe np.kokpitu dla Cesny.Dodatkowa trudność polega na sprzeczności konfiguracji PC dla wymienionych symulatorów.Postanowiłem przejrzeć na forum viperpits jaką stosują konfigurację PC pod kątem realizacji MFD oraz FalconGauges.
Niestety został zlikwidowany Znak,gdzie od lat kupowałem komputery i mogłem u nich dokonywać modyfikacji sprzętu.Teraz jestem zmuszony prosić kolegów z forum o wsparcie po wstępnym rozeznaniu tematu.Szkoda,że nie ma specjalisty z naszego forum w temacie komputery w Poznaniu.
-
Szkoda,że nie ma specjalisty z naszego forum w temacie komputery w Poznaniu.
W Poznaniu obecnie najlepiej chyba kupować sprzęt w Proline (mają sklep m.in. na Wildzie i na Ratajczaka). Znak co prawda upadł ale przejęła go inna firma http://www.inwazjapc.pl/
Są też mniejsze sklepy. Swego czasu polecano mi http://www.digitronik.pl/
-
Ostatnio wpadłem na pomysł skonstruowania modułu do radia do FS-a. Ma to być coś w rodzaju multiradia. Potrzebne elementy to
Czy udało Ci się coś poskładać? Projekt jest obiecujący.
-
MCP Zajaca znajdziesz w wątku o Mjoyu ;)
lub rozpoczynam budowe np.kokpitu dla Cesny
Cessny ;)
-
Zmontowałem na szybko układ, który docelowo ma być FSLCD :) Podłączyłem potencjometry, zasilanie. Po włączeniu zasilacza ekran się podświetla, można regulować jasność podświetlenia i kontrast, ale wyświetla się tylko jedna linia. Według informacji z linku od Zająca http://mfora.pl/viewtopic.php?t=1926 może to oznaczać uszkodzenie wyświetlacza. Z kolei tutaj http://radzio.dxp.pl/hd44780/hd44780_podstawy.htm piszą, że tak ma być. O co chodzi? Tutaj zdjęcie wyświetlacza.
(http://img40.imageshack.us/img40/3447/dsc02588.th.jpg) (http://img40.imageshack.us/my.php?image=dsc02588.jpg)
-
Domyślam się,że kupiłeś LCD 2x16 i moim zdaniem wszystko jest o.k.Pod podanymi przez Ciebie linkami są 2 wyświetlacze 4x20 oraz 2x16.W pierwszym są wyświetlane 2 linie 1 oraz 3 w drugim przykładzie tylko 1 linia tak jak u Ciebie.
-
Tak, wyświetlacz to istotnie 2x16. Nie wiedziałem, że to ma znaczenie. Dzięki Vito :020:
-
No i stało się :( Kupiłem przejściówkę ExpressCard->LPT i niestety nie jest różowo. System widzi ją jako drukarkę USB. Także przestrzegam przed pochopnym zakupem. Myślę jeszcze o tym http://www.allegro.pl/show_item.php?item=641796294 Jeśli się nie sprawdzi, to tylko OpenCockpits. W końcu ma działać na USB http://www.andare-ing.com/uploads/Manual_USBLcd_ingles.pdf
Pozdrawiam
mickey
-
Kupiłem przejściówkę ExpressCard->LPT i niestety nie jest różowo. System widzi ją jako drukarkę USB.
Myślę,że ktoś na naszym forum Tobie coś doradzi.Nie wierzę,że jest to problem nie do rozwiązania.Zaletą LPT jest to,że porogram LSLCD jest prosty(tak myślę).
Jeśli zastosujesz sterownik OC to musisz się liczyć z tym,że będziesz musiał wejść w ich soft.Nie stosowałem tego sterownika u siebie ponieważ w programie FAST współpracującym z Falconem ta opcja nie współpracuje z SIOC.
W przypadku FS nie powinno być problemów,ale musisz się liczyć z tym,że będziesz musiał napisać jakiś skrypt w którym będą zmienne do wyświetlenia powiązane z FS oraz SIOC.Ponieważ nie robiłem skryptu pod FS to nie będę mógł Tobie pomóc.Zajrzyj na stronę OC i zobacz na forum lub lepiej zadaj pytanie.Ja też pytałem i zawsze otrzymałem odpowiedź.
Jeśli będziesz coś zamawiał w OC daj znać na naszym forum,może ktoś się dołączy do listy
pozdrawiam
-
Myślę,że ktoś na naszym forum Tobie coś doradzi.Nie wierzę,że jest to problem nie do rozwiązania.Zaletą LPT jest to,że porogram LSLCD jest prosty(tak myślę).
Rzecz w tym, że zasięgnąłem języka w supporcie producenta. Oto, co odpisali:
Dear Delockcustomer,
thank you for having placed your trust in us.
This adaptor makes available no LPT connection!
It is not possible to emulate over this driver a LPT port!
The provided connection is a virtual USB connection!
These adapter is a plug&play device and is ordinarily automatically recognised by the operating system
No other driver is available!
A solution via USB is not available!
Yours sincerely
Dietmar Burgund
Delock Support
Please, send always all present e-mail \'s to your inquiry with.
-------------Vertrieben durch / distributed by---------------------------------------
Tragant Handels- und Beteiligungs GmbH
Beeskowdamm 13/15 14167 Berlin - Germany
HRB 45788 AG Berlin-Charlottenburg UStID(VAT). DE 156 330 245
Geschäftsführer: Dipl.- Ing. A. Ebrahimi
www.tragant.de
----------------------------------------------------------------------------------!
Original Message processed by David InfoCenter
Subject: Delock Support Anfrage 1243248468 (25-Mai-2009 12:47)
From: support@delock.de
To: support@delock.de
Folgende Nachricht wurde unter www.delock.de im Supportformular hinterlassen:
Produkt: 66215 Express Card > 1x parallel
Betriebsystem: Windows XP Vista 32
Chipsatz: Seriennummer:
Kaufdatum:
Fehlerbeschreibung:
Why this adapter is recognizing by Win Vista as an USB Printer? I need a \'regular\' LPT port not an USB printer. Is there any solution?
Dlatego też postawiłem krzyżyk na tej 'przejściówce'. Za te pieniądze (180pln) była by płytka Master + USBLcd od OpenCockpits. :( Z tego, co wiem, to są skrypty pod FSa, także wierzę, że nie przysporzy to problemów.
Pozdrawiam
mickey81
-
Witam
Ja fslcd używam poprzez inna przejściówkę pci-lpt http://www.morele.net/kontroler-4world-1-x-port-rownolegly-parallel-na-pci-04607-148329/ i działa ok, ale to chyba inna konstrukcja. Mam za to inny problem. Zamierzałem podłączyć do kompa więcej wyświetlaczy / min 3 / czyli dwa fslcd - dlatego właśnie kupiłem dodatkową kartę pci-lpt / działa bardzo dobrze /, ale gdy uruchamiam drugą "kopię" programu FSLCD otrzymuje taki komunikat :
(http://img7.imageshack.us/img7/9770/fslcd01y.th.jpg) (http://img7.imageshack.us/my.php?image=fslcd01y.jpg)
i koniec. Na to wygląda, że z jednego peceta można obsłużyć tylko dwa wyświetlacze - jeden program, mimo, że mam dwa porty LPT. Jak ktoś ma pomysł jak to obejść to proszę o pomoc.
Mam też inne pytanie czy skomplikowany byłby układ sterujący na usb takimi wyświetlaczami http://www.tme.eu/wyswietlacz-led-9mm-j-czerwony-anoda/arts/pl/a06/kw1-301aoa.html. W dużej części samolotów do fs2004 takie właśnie są np. boeing 737 - chyba najpopularniejszy.
pozdrawiam Zając
-
no tak PCI -> LPT zadziała 100%, bo to po prostu sprzętowy port równoległy. W przypadku laptopa jedynym rozsądnym wyjściem wydawało się ExpressCard (nowsza architektura niż PCIMCIA). Niestety, w moim przypadku się nie sprawdziła. Spróbuję jeszcze z replikatorem portów pod USB, a jak nie zadziała, to ja się poddaję. :(
-
Witam,
Mickey81 szkoda,że nie spytałeś Zajca o kartę.Jego karta jest o wiele tańsza od Twojej.
Karta z OC może sterować 4 wyświetlaczami LCD.Karta pracuje autonomicznie czyli nie potrzeba karty Master.Jest to rozwiązanie dla Zajca.Nie jestem pewien czy jest potrzebny FSUIPC,ponieważ ja dla falcona nie potrzebowałem.Na forum OC można dowiedzieć się szczegółów a także pobrać gotowe skrypty.Zajac nie mogłem otworzyć podanych przez Ciebie linków
pozdrawiam vito_zm
-
Zajac nie mogłem otworzyć podanych przez Ciebie linków
pozdrawiam vito_zm
Sorry to link do innej strony z wyświetlaczami siedmiosegmentowymi, http://www.piekarz.pl/index.php?page=offer&item=7074 a takie mi właśnie chodzi
Zając
-
Witam,
Mickey81 szkoda,że nie spytałeś Zajca o kartę.
Ale Zając posiada przejściówkę PCI>LPT. W laptopie zupełnie bezużyteczna, chyba, że coś źle zrozumiałem. Zającu drogi, rozwiej wątpliwości ;)
BTW. Jak chciałbyś sterować te wyświetlacze?
Vito: FSUIPC jest biblioteką do FSa
Pozdrawiam
-
Ale Zając posiada przejściówkę PCI>LPT. W laptopie zupełnie bezużyteczna, chyba, że coś źle zrozumiałem. Zającu drogi, rozwiej wątpliwości ;)
Dokładnie moja karta "siedzi" w dużym kompie do laptopa się nie nadaje
A zmieniając trochę temat, kończę projektować coś w rodzaju Multiradia do FS-a opartego na pcb od gamepada / kupiony i "wybebeszony" / jednej płytce do encoderów i FSLCD. Powinno wyglądać coś w tym rodzaju.
(http://img38.imageshack.us/img38/1091/multiradiov3cdr.th.jpg) (http://img38.imageshack.us/my.php?image=multiradiov3cdr.jpg)
pozdrawiam Zając
-
Witam wszystkich,
Pozwolicie że podłącze się pod temat.
Zając. Zerknąłem na Twój ostatni post, w nim link i widzę tam wyświetlacze 7-segmentowe. Wymagają dodatkowego Hardware i soft np. z OC Displays card. Do tego jeszcze musisz mieć Master, jeśli chcesz to wszystko podłączyć do USB to jeszcze USB Expansion card. Policz sobie teraz jakie koszty musisz ponieść żeby odpalić 7-segmenst display. Pomijam już płytkę PCB, okablowanie i konfiguracje. Jeśli chcesz zrobić wyświetlacz sterowany przez USB to proponuje kupić gotowy np. taki http://cgi.ebay.co.uk/USB-Interfaced-4x20-blue-Backlight-LCD-display-module_W0QQitemZ320373759035QQcmdZViewItemQQptZUK_BOI_Electrical_Components_Supplies_ET?hash=item4a97c39c3b&_trksid=p3286.c0.m14&_trkparms=72%3A2109
Spokojnie to wysterujesz w FSLCD. Być może są tańsze ( nie szukałem) Ale, jest to najłatwiejsze rozwiązanie. Jeśli chcesz podłączyć do jednego peceta więcej niż 2 wyświetlacze to... chyba się nie da. Rozwiązaniem jest- USB LCD card z OC, dwa komputery w sieci poprzez FSUIPC i WideFs. Na każdym można podłączyć po dwa. Lub tez, na jednym USB (taki jak podałem) i LTP. Ale czy taka konfiguracja zadziała nie jestem pewny, nie testowałem. Wszystko to tyczy się FS.
To mój pierwszy post na tym forum. Pozdrawiam zatem wszystkich serdecznie :001:
-
Zając. Zerknąłem na Twój ostatni post, w nim link i widzę tam wyświetlacze 7-segmentowe. Wymagają dodatkowego Hardware i soft np. z OC Displays card. Do tego jeszcze musisz mieć Master, jeśli chcesz to wszystko podłączyć do USB to jeszcze USB Expansion card. Policz sobie teraz jakie koszty musisz ponieść żeby odpalić 7-segmenst display. Pomijam już płytkę PCB, okablowanie i konfiguracje
To co pisze EGHI jest prawdą,ale dotyczy LED 7-segment.Myślę,że Zajac podał zły link,ponieważ cały czas była mowa w wyświetlaczach opartych na HD44780.
Karta USB Lcd kosztuje 20 EUR w postaci kitu do montażu.Jeśli kupimy dodatkowy przewód dla połączenia 4 HD44789 to trzeba zapłacić dodatkowo 8 EUR.
Tak jak wspomniałem karta pracuje samodzielnie nie potrzeba innych kart OC.Na jednej karcie można połączyć fizycznie 4 HD44780 co umożliwia (soft) wyświetlenie 20 wirtualnych "display" np.tekstów.Nie jestem pewien czy można do pc dołączyć kilka kart,aby zwiększyć liczbę wyświetlaczy.Można zapytać na forum OC.
ps
EGHI witamy serdecznie na naszym forum.
-
A dlaczego nie stworzyć własnego, tańszego i przystosowanego do "naszych" potrzeb rozwiązania ? Układ do sterowania wyświetlaczem z HD44780 (a nawet kilkoma naraz) i podpinany pod RS232 (wiem, że tak samo jak LPT jest już rzadkością w nowych PC ale przejściówki RS232->USB są dostępne i działają bardzo dobrze) jest dość prosty i dużo tańszy od rozwiązań OC itp. Pozostaje jedynie kwestia oprogramowania bo wtedy trzeba program do obsługi (jak FSLCD) napisać samemu. Nieskromnie napiszę, że od kilkunastu dni (niestety z przerwami - brak czasu), taki układ jak i oprogramowanie sterujące do niego, powstaje na moim PC (lubię rozwiązania tanie i dopasowane do moich potrzeb a nie podoba mi się wydawanie sporych ilości europejskiej waluty na rozwiązania, które dobre dla innych niekoniecznie są dobre dla mnie). Przy czym ma to być program do obsługi joystick'ów, wyświetlaczy, diód itp., oparty na prostych skryptach (podobnie jak SIOC ale w chwili obecnej jest to bardzo rozbudowany plik XML) no i przede wszystkim dla FSX ale "budowa" nie wyklucza użycia także FSUIPC. Nie wiem kiedy i czy w ogóle skończę to rozwiązanie, ale niewątpliwie chyba nie warto wydawać pieniędzy na zbędne rzeczy, a tak jak pisałem układ pod RS232 (poprzez przejściówkę do USB) do sterowania wyświetlaczami czy diodami to naprawdę jest koszt kilkunastu złotych (płytka trawiona w domu ale na upartego można to zrobić na "pająka"). Jedyny problem to oprogramowanie.
-
A dlaczego nie stworzyć własnego, tańszego i przystosowanego do "naszych" potrzeb rozwiązania ? (...) jak pisałem układ pod RS232 (poprzez przejściówkę do USB) do sterowania wyświetlaczami czy diodami to naprawdę jest koszt kilkunastu złotych (płytka trawiona w domu ale na upartego można to zrobić na "pająka"). Jedyny problem to oprogramowanie.
To może podzielisz się swoim projektem. Na naszym forum jest naprawdę kilku świetnych specy, którzy na pewno pomogą. Wystarczy prześledzić wątek o Mjoyu, potrzeba było extra enkoderów? No to chłopaki wymyślili układ. Przejściówki USB -> RS232 istotnie działają wyśmienicie, mogę to potwierdzić, sam korzystam z takiej w laptopie i jest ona widziana jako 'normalny' port COM.
Pozdrawiam
mickey81
-
Jeśli tylko będzie jakaś funkcjonalność, która pozwoli choćby np. wyświetlać ustawienia radia to pokażę rozwiązanie, a póki co wszystko jest w fazie rozwojowej. Speców na forum jest wielu i gdyby tak rozpocząć duży projekt ala OC czy FSBUS to pewnie powstało by nie gorsze uniwersalne rozwiązanie :)
-
Jedyny problem to oprogramowanie
No właśnie,w tym cały problem.Gdyby nie Damos nie byłoby "płyty enkoderów".Bez aktywnej współpracy programistów "hardwarowiec" nic nie wymyśli.Ja jestem zmuszony korzystać z gotowych programów,ponieważ nie potrafię ich napisać.
2 lata temu prosiłem na viperpits o rozwiązanie sterowania DED w falconie (można to zrobić na HD44780 4x20 znaków).Radzono abym kupił klawiaturę G15 i zastosował program G15 Viper napisany przez AiRdAnce i tak zrobiłem.Teraz są inne rozwiązania,ale trzeba za gotowy panel DED zapłacić.
Ja chętnie pomogę w dziedzinie elektroniki,ale bez programisty nie ma szans na sukces
pozdrawiam,vito_zm
-
(...) kończę projektować coś w rodzaju Multiradia do FS-a opartego na pcb od gamepada / kupiony i "wybebeszony" / jednej płytce do encoderów i FSLCD. Powinno wyglądać coś w tym rodzaju.
(http://img38.imageshack.us/img38/1091/multiradiov3cdr.th.jpg) (http://img38.imageshack.us/my.php?image=multiradiov3cdr.jpg)
pozdrawiam Zając
Chcemy więcej! ;)
Dziel się Zającu, bo projekt super.
Nawiasem mówiąc USB LCD Card kompletna i zmontowana kosztuje ok 124 pln przy kursie euro 4,43. Do tego przesyłka.
Czy to naprawdę taki duży wydatek, za działający produkt obsługujący 4 wyświetlacze?
Pozdrawiam
mickey81
-
(...)Myślę,że Zajac podał zły link,ponieważ cały czas była mowa w wyświetlaczach opartych na HD44780.
Link dobry - miałem właśnie siedmiosegmentowe na myśli, takie jak w OC lub FSBUS, i mam pytanie czy sterowanie nimi jest skomplikowane i czy się da w miarę prosty sposób wykorzystać do budowy kokpitu.
Chcemy więcej! ;)
Dziel się Zającu, bo projekt super.
Dzisiaj jadę na zakupy "sprzętowe" i w przyszłym tygodniu zacznę wszystko składać i oczywiście wszystko opiszę
Zając
-
Zając. Zerknąłem na Twój ostatni post, w nim link i widzę tam wyświetlacze 7-segmentowe. Wymagają dodatkowego Hardware i soft np. z OC Displays card. Do tego jeszcze musisz mieć Master, jeśli chcesz to wszystko podłączyć do USB to jeszcze USB Expansion card. Policz sobie teraz jakie koszty musisz ponieść żeby odpalić 7-segment display. Pomijam już płytkę PCB, okablowanie i konfiguracje. Jeśli chcesz zrobić wyświetlacz sterowany przez USB to proponuje
Wersja LED 7- seg.jest w opcji zakupu w OC nieopłacalna i bez sensu.
Można rozpatrzyć zakup karty USB Lcd,która kosztuje 20 EUR i umożliwia podłączenie 4 wyświetlaczy LCD.Przesyłka jest dosyć droga 15EUR + 10EUR WAT.
Gdyby ktoś z forum zrobił zamówienie w OC to warto zrobić listę chętnych na zakup innych elementów w OC,zmniejszyłoby to koszt przesyłki.
-
Jeżeli byli byście gotowi złożyć duże zamówienie to ja jestem chętny mam jednak nadzieję , że swoją obecnością was nie zniechęcę :008: (potrzebuję paneli do arbuza A320tki)
-
Przesyłka jest dosyć droga 15EUR + 10EUR WAT.
Jesteś pewien?
Z tego, co się orientuję przy zakupach w krajach Unii nie płacisz Vatu, bo jest to import wewnętrzny. Formalnie powinieneś zgłosić przesyłkę do Urzędu Celnego, ale nieformalnie... ;)
-
Płaci się Vat przy zakupie w OC.
Tutaj przykład:
Products
2 x 8 positions rotary switch 12.00EUR
Sub-Total: 12.00EUR
NORMAL delivery (Using Spanish Correos agency) (Shipping to United Kingdom 0.5 Kg(s)): 8.62EUR
IVA (VAT): 3.30EUR
Total: 23.92EUR
-
Przy zakupach w Unii płaci się VAT, jak najbardziej, ale według stawek kraju w którym się kupuje. Czyli zazwyczaj odrobinę niższych niż w Polsce, ale nie wszędzie. Urzędu celnego w takie zakupy nie trzeba mieszać, VAT to nie cło.
-
To może podzielisz się swoim projektem.
Coś zaczęło działać, jeszcze długa droga ale...częstotliwości radia z powodzeniem wyświetlam na małym wyświetlaczu 2x16. Objawił się jakiś dziwny problem, przy szybkiej zmianie częstotliwości bądź "swap" może skończyć się tym, że jedna z częstotliwości ma nieaktualną wartość na wyświetlaczu, ale po testach wygląda mi to na problem z układem sterującym wyświetlaczem i muszę nad tym posiedzieć. Ale ważne jest, że coś działa. Jak uporam się z problemem to napiszę coś więcej.
-
Witam,
mam pytanie do kolegów programistów.Chciałbym zaprogramować jedną kość PIC 16C745.Można kupić programator za 100zł,ale dla jednej kości to nie ma sensu.Mogę wykonać sam prosty programator za parę zł,ale mam problem z softem dla tej konkretnej kości.Jeśli ktoś może mi pomóc będę wdzięczny
pozdrawiam,vito_zm
PS
Codeking moje gratulacje, coś drgnęło w temacie wyświetlaczy.
-
vito_zm - ja nie pomogę, jedyna wiedza jaką posiadam dot. uC to AVR, i to bardzo podstawowa.
Problem rozwiązałem - okazało się oczywiście, że popełniłem drobny ale jakże istotny błąd w kodzie. Ale teraz działa tak jak trzeba. Więcej info wkrótce.
-
Czekamy z niecierpliwością. Niestety u mnie mam problem, prawdopodobnie uszkodziłrm płytkę od gamepada w czasie wylutowywania kabelków. "Nieznane urządzenie USB" :015:. Więc na razie przerwa, ale poczekam na wynik prac nad wyświetlaczem, na pewno da się zaadaptować ten projekt do MULTIRADIA i od razu deklaruje pomoc, jak by taka była potrzebna i będę umiał.
Pozdrawiam z
Zając
-
Po kilku godzinach pisania, testowania, konfigurowania, zrobiłem mały kawałek, który może być przydatny do multiradia. Ogólnie moje rozwiązanie to przede wszystkim oprogramowanie. W nim siła i w nim słabość. To co nie podoba mi się w SIOC czy FSBUS, to to, że nie mogę zrobić sobie np. wyświetlacz pod RS232 i obsługiwać go pod którymś ze wspomnianych rozwiązań, rozumiem, że to oprogramowanie nie zna mojego sprzętu ale gdyby było dostępne jakieś SDK, dzięki któremu wprowadziłbym interakcję pomiędzy w/w oprogramowaniem a moim sprzętem. No i druga rzecz, lubię sam coś podłubać, polutować i cieszyć się jak dziecko kiedy coś zacznie działać.
Program sterujący to tak naprawdę tylko obrabiarka danych, które przychodzą do niego, po obróbce wyrzuca je z siebie np. do FSX. Służy on głównie do obsługi skryptów sterujących, które pisze użytkownik. W skrypcie używa się zmiennych wejściowych i wyjściowych (i wewnętrznych ale to jest nieistotne teraz). Zmienne wejściowe to np. stan przycisku w joystick'u, częstotliwość radia COM1 w FSX itp. Zmienny wyjściowy to np. jakiś obszar na wyświetlaczu, dioda, parametry w FSX. Zmiennych wejściowych jak i wyjściowych dostarczają do programu głównego moduły wejścia/wyjścia. Można stworzyć sobie dowolny moduł (z odpowiednim interfejsem żeby program główny mógł z niego skorzystać), do obsługi wyświetlacza na LPT, RS232 czy USB, pobierający dane z FSX czy FS9, odczytujący stan joystick'ów itp. Tak więc nie przywiązuje się praktycznie do niczego, bo program główny korzysta tylko ze zmiennych które dostarczają moduły i skryptu który jest tworzony przez użytkownika. Nie interesuje go skąd moduł wziął zmienne i gdzie wyśle ich nowe wartości. Więc nie ma ograniczenia co do sprzętu (jeśli potrafisz go obsłużyć programowo to nie ma problemu) i oprogramowania (o ile istnieje odpowiedni interfejs - SimConnect, FSUIPC).
Skrypty to takie małe programiki, które reagują na zmiany wartości wybranych zmiennych (podobnie jak w SIOC). Niestety w chwili obecnej skrypty mają format XML i to bardzo rozbudowanych. Zrobiłem tak na początek, żeby nie głowić się na początku nad problemem parsera itd. Może kiedyś powstanie format przyjazny dla ludzi.
Jeśli chodzi o sprzęt a właściwie o wyświetlacz na HD44780. Pisałem wcześniej, że obsługa jest prosta i tak jest. Ale od początku. Wymyśliłem sobie kiedyś, że dobrze byłoby mieć 3 podstawowe urządzenia: wyświetlacz LCD, wyświetlacze LED (siedmiosegmentowe) i diody LED. Przyciski, przepustnice i enkodery są realizowane przez MJoy'a więc w połączeniu te kilka urządzeń pozwoliłoby na stworzenie uniwersalnych modułów kokpitu: radio, auto-pilot, dźwignia podwozia itp. Żeby nie komplikować sprawy, wybrałem interfejs RS232 do komunikacji PC->urządzenie. Kiedyś na elektroda.pl przeczytałem, że do układu MAX232 (umożliwia komunikację PC <-> uC AVR) można podpiąć kilka uC, przy czym wszystkie one mogą odbierać dane a wysyłać...to już mnie nie interesuje. Tak więc, jeden port RS232 (a jak brak to z powodzeniem można wykorzystać przejściówkę RS232<->USB) i kilka urządzeń do niego podpiętych. Do tego prosty protokół danych, tak żeby np. rozkaz zapalenia diody był wykonany tylko przez odpowiedni układ, reszta go ignoruje.
Wyświetlacz na HD44780 podłącza się do uC właściwie bez żadnych dodatkowych elementów (potrzebny tylko przewód i potencjometr do ustawiania kontrastu wyświetlacza). Taki mały uC jak Attiny2313 może spokojnie obsłużyć 7 wyświetlaczy 2xXX (2x16, 2x20 czy 2x40, nieważne). Czyli układ z wyświetlaczami można stworzyć za bardzo małe pieniądze w porównaniu z innymi rozwiązaniami. Obsługa diód LED to też prosta sprawa. Wyświetlacze siedmiosegmentowe to również nie jest specjalnie trudny temat. Dla wyświetlaczy na HD44780 i diód mam wstępnie zaprojektowane płytki do domowego trawienia - muszę wykonać prototypy i sprawdzić. Na razie sprawdzam na płytce uniwersalnej.
Tak więc z grubsza opisałem to co staram się wykonać. Poniżej dorzucam link do filmiku na którym pokazuje przykładową konfigurację i działanie wyświetlacza, widok tego prostego urządzenia, link do pliku z konfiguracją tego wyświetlacza (RS232HCDevices.xml) oraz plik skryptu (TestowyProfil.xml), żeby można było zobaczyć jak wyglądają skrypty w tej fazie rozwoju (proszę uwierzyć - one działają !). Aha, skrypt skryptem, ale każdy moduł ma właściwie też swoją konfigurację w której np. dla wyświetlaczy definiuje się obszary znakowe do których będzie wpisywany jakiś tekst.
Te dwie płytki to proste prototypowanie :)
(http://img36.imageshack.us/img36/425/dsc00694p.th.jpg) (http://img36.imageshack.us/my.php?image=dsc00694p.jpg)
I trzy zrzuty programu
(http://img39.imageshack.us/img39/1774/program1.th.jpg) (http://img39.imageshack.us/my.php?image=program1.jpg)
(http://img36.imageshack.us/img36/2538/program2.th.jpg) (http://img36.imageshack.us/my.php?image=program2.jpg)
(http://img35.imageshack.us/img35/3528/program3.th.jpg) (http://img35.imageshack.us/my.php?image=program3.jpg)
Filmik
http://www.youtube.com/watch?v=rjIaqFcUot0 (http://www.youtube.com/watch?v=rjIaqFcUot0)
Konfiguracja wyświetlacza
http://angus.foxnet.pl/fs/RS232HCDevices.xml (http://angus.foxnet.pl/fs/RS232HCDevices.xml)
Skrypt
http://angus.foxnet.pl/fs/TestowyProfil.xml (http://angus.foxnet.pl/fs/TestowyProfil.xml)
PS. Jak coś namieszałem lub niejasno napisałem to pytać.
-
Witam,
ponieważ temat zastosowanie LCD do wyświetlania parametrów symulatora w panelach jest na tapecie to postanowiłem napisać swoje doświadczenia z tym związane.
Co najmniej od 2 lat chciałem zrealizować wyświetlanie na LCD (4x20) DED z falcona.Znalazłem w sieci projekt opartych na LPT oraz USB.Napisałem do autora Red Dog (nickname).Jego rozwiązanie pozwalało sterować nie tylko DED,PFL ale także RWR,ale było na nasze warunki drogie,dlatego poradził mi zastosować najtańsze w chwili obecnej rozwiązanie oparte na klawiaturze Logitech G15.I tak zrobiłem.
Parę słów na temat tego rozwiązania.Trzeba kupić najlepiej na Allegro używaną klawiaturę z której bierzemy LCD oraz sterownik.Potrzebujemy jeszcze program AirdAncE o nazwie G15 Viper z strony
http://www.viperpits.org/smf/index.php?topic=3232.0
Inne rozwiązanie polega na zastosowaniu programu FalconGauges oraz LCD połączonego do karty graficznej.Jeśli chcemy zastosować 2 PC-y to musimy użyć program komunikacyjny F4Glass oraz oczywiście FalconGauges.
Jest jeszcze inna możliwość zrobić to samemu.Oto przykład
http://www.viperpits.org/smf/index.php?topic=4381.0
Aby to zrealizować to trzeba poznać tzw.dzieloną pamięć share memory,gdzie są wszystkie dane symulatora i można je tylko przechwycić a nie modyfikować tak jak w FS.Na forum viperpits jest paru programistów,którzy umieją z tego korzystać i robią wspaniałe programy np.FalconGauges oraz MFD Extractor.Poznałem wirtualnie jednego z nich mihi4,który napisał program FAST łączący SIOC z OC z symulatorem Falcon.Na bazie tego programu buduję kokpit F16.W jego programie jest opcja sterowania DED oraz PFL,ale nie działa.Obiecał,że może do tego wróci (obecnie zajęty jest budową domu).
Na viperpits jest teraz w modzie PHCC i pod ten hardware piszą programy.Tak jak wspomniałem nie jestem programistą i jestem skazany na ich pomoc,dlatego gdy coś nie rozumiem to pytam u źródła tzn.programistów.
Teraz parę słów na temat sterowania LCD w FS.Tutaj sytuacja wydaje się łatwiejsza,ponieważ jest gotowe rozwiązanie.Jedno to uproszczone ,które stosuje Zajac z ograniczeniem do 2 LCD (LPT) oraz karta OC na 4 LCD.Można napisać samemu program tak jak robi to codeking.Tyle moich doświadczeń w tym temacie
pozdrawiam,vito_zm
-
Moje gratulacje codeking.Jestem coraz większym optymistą.Ponieważ nic nie robiłem na H44780 to mam kilka trywialnych pytań.Rozumiem,że można kupić alfanumeryczny wyświetlacz z sterownikiem HD44780 w opcji 2x20,4x20 lub innej liczby znaków w zależności od potrzeb?
W Twoim rozwiązaniu musiałeś przejść z interfejsu równoległego na szeregowy RS232.Jak to zrobiłeś,mam na myśli układ scalony.
Ponieważ nie jestem programistą to nie mam pytań związanych z programem.Jestem zainteresowany Twoim pomysłem,ale dla innego symulatora Falcona.Tutaj niestety tylko programista może rozwiązać ten problem.Jest potrzebna umiejętność przechwytywania danych z share memory i ich przesyłanie na port.
Jeśli chodzi o uniwersalny hardware do sterowania LED,LED 7-seg oraz LCD to można to rozwiązać na kilka sposobów.Najprostsze rozwiązanie zastosował OpenCockpits w swojej wersji początkowej kilka lat temu.Była oparta na porcie LPT i ja ją zrealizowałem.Ta wersja jest już przestarzała i należy nowe rozwiązanie oprzeć na porcie USB i tak zrobili w OC.Idea sterowania hardware jest prosta i opiera się na cyklicznym odpytywaniu i wysyłaniu danych.Hardware jest ważne,ale najważniejszy jest program sterujący tym wszystkim.I tutaj SIOC jest tego przykładem.
Wracając do naszych problemów to można pomyśleć o rozwiązaniu codeking,ale cały ciężar tego pomysłu spoczywa na programistach.Jest już pewien postęp i to rokuje nadzieję.
Wracając do interfejsu to można oczywiście zastosować rozwiązanie z RS232,które jest lepsze od LPT.Mam nadzieję,że codeking będzie kontynuował swoje prace i odniesie sukces.
-
Rozumiem,że można kupić alfanumeryczny wyświetlacz z sterownikiem HD44780 w opcji 2x20,4x20 lub innej liczby znaków w zależności od potrzeb?
Tak, do wyboru jest kilka wersji, przy czym z opisu na stronie http://radzio.dxp.pl/hd44780/4x40/ (http://radzio.dxp.pl/hd44780/4x40/) wynika, że sam sterownik udźwignie max 80 znaków czyli 2x40. 4x40 to już jakby dwa wyświetlacze 2x40 połączone ze sobą, ale nie ma to dużego wpływu na sposób sterowania.
W Twoim rozwiązaniu musiałeś przejść z interfejsu równoległego na szeregowy RS232.Jak to zrobiłeś,mam na myśli układ scalony.
Nic szczególnego nie trzeba robić, uC AVR'y mają wbudowane USART'y czyli obsługę transmisji szeregowej. Jedyną konieczną rzeczą jest przetworzenie sygnału z RS232 tak by był odpowiedni dla AVR. Wykonywane to jest przez mały układzik MAX232. Jest też taki układ dla USB (FT232 czy jakoś tak) ale jeśli się nie mylę to jest układ z wbudowaną przejściówką RS232<>USB.
Jest potrzebna umiejętność przechwytywania danych z share memory i ich przesyłanie na port.
To jest kwestia posiadania gry i wiedzy które offsety czytać.
Jeśli chodzi o uniwersalny hardware do sterowania LED,LED 7-seg oraz LCD to można to rozwiązać na kilka sposobów.
Tak, możliwości jest wiele, mi osobiście podobają się rozwiązania najprostsze i najtańsze, co nie wyklucza, że dobre. Mało elementów i nieskomplikowana budowa i proces uruchamiania (czyli tak jak w przypadku genialnego MJoy'a) powoduje, że wiele osób bez doświadczenia elektronicznego czy programistycznego sobie poradzi.
Wracając do interfejsu to można oczywiście zastosować rozwiązanie z RS232,które jest lepsze od LPT.
I ma tą przewagę, że przejściówki na USB działają :)
Mam nadzieję,że codeking będzie kontynuował swoje prace i odniesie sukces.
Sukcesem jest to, że dotarłem do tego miejsca :) A projektu nie zarzucę dopóki nie będzie działał przynajmniej tak, żebym mógł zrealizować swoje pomysły na proste panele do FSX.
-
Codeking, mógłbyś dokładniej opisać jak wygląda komunikacja z HD44780 w twoim rozwiązaniu? Wczoraj napisałem aplikację, która wyciąga z pamięci współdzielonej Falcona tekst z PFL i wyświetla to na LCD 2x24. Jednak w moim rozwiązaniu ja bezpośrednio wysyłam dane do kontrolera (przez LPT). U ciebie muszą one najpierw przejść przez ATtiny2313 i dopiero potem uC przesyła je dalej do LCD. W jakim języku trzeba go programować? Mógłbyś zamieścić jakieś schematy budowy dla swojego rozwiązania? Poza PFL chciałbym zbudować jeszcze DED a i kiedyś może nawet MFD i RWR (czy za pomocą twojego rozwiązania da się pogodzić wyświetlacze alfanumeryczne i graficzne?). Ciekaw jestem też w jakim języku napisałeś swoją aplikację. Nie wiem czy to tylko moje urojenia, ale mało który program do obsługi wyświetlaczy LCD jest napisany w moim ukochanym C++.
-
Witam,
oprócz postów w tym wątku koresponduję z kolegami na priv.Nasuwa się następujący wniosek dotyczący budowy paneli.Czy jest możliwa współpraca lub koordynacja naszych działań.Dobrym przykładem był projekt Damosa,który przy współpracy kilku kolegów został sprawnie zrealizowany.Teraz na tapecie jest wyświetlacz alfanumeryczny HD44780.Z tego co wiem to 2 kolegów próbuje rozwiązać ten problem jeden wykorzystuje interface LPT drugi COM.Następna różnica w projekcie to symulatory FS oraz Falcon.Myślę,że pomimo pewnych różnic w założeniach można zrobić uniwersalny sterownik,który będzie sterował układ HD44780 oraz współpracował z USB.Są uP które mają wbudowany interface szeregowy (USB) np.PIC 16C745.Podobnie można pomyśleć o protokole wymiany informacji PC uP.Pozostają różnice w bloku programowym współpracującym z symulatorami FS oraz Falcon,ale to nie zmienia faktu,że do tego momentu protokół komunikacyjny oraz hardware może być wspólne.W protokole mogą być opcje uwzględniające np.ilość wyświetlanych lini w zależności od zastosowania,ale to są szczegóły.
Moim zdaniem to 90% pracy przy tym projekcie musieliby wykonać programiści programująć uP oraz aplikacje w PC a resztę elektronicy oraz projektanci pcb.Co sądzicie o tym pomyśle?
-
Pomysł jest OK. Cel, pomimo różnych symulatorów, jest ten sam - kilka wyświetlaczy LCD na jednym kablu (i najlepiej USB właśnie, bo ja na przykład COM już nie posiadam a i LPT wychodzi już z użytku). Jak dla mnie problemem może być język w jakim miałoby zostać napisane oprogramowanie. Ja jestem zatwardziałym si plus plusowcem :)
-
Wyświetlacz podłączyłem do Attiny2313 wg. opisu na stronie http://radzio.dxp.pl/hd44780/hd44780_avr_4-bit_rw_c.htm (http://radzio.dxp.pl/hd44780/hd44780_avr_4-bit_rw_c.htm). Tam jest też również zamieszczony kod z funkcjami do sterowania wyświetlaczem (kod dla uC) w C i to właśnie C używam do programowania uC. Attiny2313 podpiąłem przez MAX232 do RS232 przy PC. Zrobiłem prosty protokół, który będzie mi też służył do sterowania innymi urządzeniami (diody LED i wyświetlacze LED). Nie wiem jak wygląda sterowanie wyświetlaczami graficznymi, jeśli jest to podobne do HD44780 to nie ma problemu.
Jeśli chodzi o aplikację desktopową to wg. mnie nie ma lepszego narzędzia do szybkiego tworzenia oprogramowania od C# - szybko, prosto i bezboleśnie.
vito_zm - można coś takiego zrobić, trzeba tylko ustalić jak to wszystko ma wyglądać i działać. Stworzyć układ, wsad dla uC i przyjąć jakiś protokół komunikacji z urządzeniem. Moja wiedza dot. uC jest na poziomie sterowania wyświetlaczem i diodami - czyli niewielka (aczkolwiek do prostej zabawy wystarczająca :) ) USB jest jak najbardziej najlepszym rozwiązaniem ze względu na uniwersalność. LPT rzadko się spotyka. RS232 również, aczkolwiek tu są dostępne przejściówki. Nigdy nie programowałem USB po stronie Windows, może ktoś z forumowiczów ma w tej dziedzinie jakieś doświadczenia. Ale wszystko jest dla ludzi. Jeśli będę w stanie pomóc to chętnie pomogę.
-
Witaj Gerrah! Ciesze się, że w końcu odezwałeś się w tym wątku ! :)
Co sądzicie o tym pomyśle?
Jak już wiesz - jestem jak najbardziej "za". Tym bardziej, że uniknęło by się dublowania pracy i stworzenia kilku niekompatybilnych rozwiązań.
Pomysł jest OK. Cel, pomimo różnych symulatorów, jest ten sam - kilka wyświetlaczy LCD na jednym kablu
Tylko wyświetlaczy? Można by od razu dodać jeszcze trochę diod.
najlepiej USB właśnie, bo ja na przykład COM już nie posiadam a i LPT wychodzi już z użytku
IMHO wniosek oczywisty. USB jest obecnie najbardziej uniwersalną magistrala.
Jak dla mnie problemem może być język w jakim miałoby zostać napisane oprogramowanie. Ja jestem zatwardziałym si plus plusowcem :)
a to akurat zaleta :) jeśli znasz QT to można zrobić coś multiplatformowego. Warstwa software'u komunikująca się ze sprzętem POWINNA być napisana w C++. Programowanie mikrokontrolera to tez C++ lub C. Po zdefiniowaniu protokołu komunikacji z modułem sterującym graficzne nakładki można by robić w dowolnym języku: (C++ , C#, VB, Java, Python, Perl ....) BTW - używasz boost'a i template'ów ?
Jeśli chodzi o aplikację desktopową to wg. mnie nie ma lepszego narzędzia do szybkiego tworzenia oprogramowania od C# - szybko, prosto i bezboleśnie.
Z pewnością jest to bardzo efektywne narzędzie do robienia wszelkiego rodzaju programów narzędziowych dla Windows. Szybko, łatwo i wygodnie.
Nigdy nie programowałem USB po stronie Windows, może ktoś z forumowiczów ma w tej dziedzinie jakieś doświadczenia.
USB jest dość złożoną materią (właśnie dla celów mojego projektu przymierzam się do przenośnej biblioteki do obsługi USB - wygląda obiecująco: "libusb" oraz "libusb-Win32" ). Jeśli chodzi jedynie o wyświetlanie czegoś na kilku wyświetlaczach LCD, to można pójść "na skróty" i użyć prymitywnej implementacji USB na Atmega16. Planowałem sobie coś innego, ale to z pewnością będzie szybsze do zrobienia. Jeśli HD44780 używa zewnętrznej linii strobującej i nie jest wrażliwy na spowolnienia transmisji, to powinno być możliwe obsłużenie kilku wyświetlaczy LCD za pomocą jednej Atmegi podłączonej do USB.
Może jednak umówić się na jakiś chat i porozmawiać o celach działania i zasobach ludzkich? Kto co może zrobić? Ile ma czasu? Jakie ramy czasowe sobie stawiamy? Czy ma być to jeden zryw, czy coś dłuższego? Tylko LCD, czy coś więcej? Open source czy nie? Multiplatform, czy nie? Poziom kompatybilności z innymi platformami i jakieś protokoły... Co wy na to?
Namawiał bym na wieloplatformowość i OpenSource - wtedy mamy szanse na pomoc ze strony ogromnej rzeszy programistów.
Z innej beczki: dobry protokół komunikacji między hostem sterującym urządzeniem a światem zewnętrznym (inne aplikacje, symulatory itd) to... sockety (!) w Linuxie to działa doskonale i gwarantuje 100% separację (logiczna i binarną) oraz niezwykłą elastyczność. A może działać nawet pomiędzy różnymi kompami... :)
-
Wiele pytań i wiele do ustalenia, trzeba jednak wziąć pod uwagę to, aby nie tworzyć przesadnie skomplikowanego i ograniczonego rozwiązania, ani nie kopiować OC czy FSBUS. Wg. mnie to prostota wykonania (dla budowniczych tzn. płytka + wgranie wsadu = gotowe urządzenie) i uniwersalność jest najważniejsza. Trzeba by zacząć zastanowić się od najniższego poziomu - sprzęt, biorąc pod uwagę stopień skomplikowania jego programowania. No i jakie moduły, proponuję sterownik dla kilku LCD na HD44780 (małe Attiny2313 bez problemu poradzi sobie z kilkoma takimi wyświetlaczami), matryca diód LED i wyświetlacze 7-segmentowe LED. Tylko czy ma być centralka do której podpinamy takie moduły czy może każdy moduł jest samodzielny. W takich projektach najgorzej jest zacząć. Przyjęcie jakiegoś jednego rozwiązania i trzymania się go do końca to jest chyba klucz do powodzenia projektu (oczywiście nie wykluczając ew. poprawek gdy wystąpią poważne problemy projektowe).
Sockety - to jest OK, urządzenia podpinane do sieci Ethernet :) Ha, to było by ciekawe rozwiązanie i niesamowicie uniwersalne!
-
prostota wykonania (dla budowniczych tzn. płytka + wgranie wsadu = gotowe urządzenie) i uniwersalność jest najważniejsza.
Oczywiście, że to jest klucz! Ilość elementów dyskretnych w rozwiązaniach OC jest zbyt duża. Im więcej można upchnąć w oprogramowaniu kości i sofcie - tym lepiej.
Sockety - to jest OK, urządzenia podpinane do sieci Ethernet :) Ha, to było by ciekawe rozwiązanie i niesamowicie uniwersalne!
Nie do końca. Stacki TCP w mikrokontrolerach maja ograniczoną ilość równoczesnych połączeń. Myślałem o tym, że oprogramowanie kontrolujące hardware jest dostępne poprzez TCP - działa jak serwer (jak X'y i GL pod linuxem). Sam hardware jest kontrolowany przez USB. Jednak spokojnie całość może siedzieć na innym kompie niż sam symulator i komunikować się po TCP.
-
Nie do końca. Stacki TCP w mikrokontrolerach maja ograniczoną ilość równoczesnych połączeń. Myślałem o tym, że oprogramowanie kontrolujące hardware jest dostępne poprzez TCP - działa jak serwer (jak X'y i GL pod linuxem). Sam hardware jest kontrolowany przez USB. Jednak spokojnie całość może siedzieć na innym kompie niż sam symulator i komunikować się po TCP.
OK, rozumiem.
Może przez najbliższe dni zebrać różne pomysły co i jak itd. a później wybrać najlepsze pomysły i połączyć je w jedno rozwiązanie, rozdzielić pracę i do dzieła.
-
Tak łatwo nie będzie :) Nie obejdziemy się bez fazy R&D oraz "proof of concept". Jednak należy zacząć od założeń...
Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn. To budzi pewne obawy odnośnie poprawności zdefiniowanych protokołów i interface'ów.
I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej :) Mnie bardziej bawi tworzenie więc dla mnie to nie problem. A dla was?
-
Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn.
Jakby kogoś interesował FSX (może w ograniczonym stopniu FS2004) to służę. Ale nie śledzę wątku regularnie, "o so chodziiii"?
-
Witam ponownie,
cieszę się,że pomysł znalazł akceptację.Szkoda,że nie mogę pomóc w dziedzinie oprogramowania chociaż mam ogólne pojęcie.Jeśli chodzi o hardware OC to zrobiono na początku prosty projekt oparty o technikę dyskretną.Następnie powstawały nowe pakiety,które były oparte o uP i rozszerzały możliwości systemu (USB Expansion) lub zastępowały stare karty (Display II) lub były nowymi kartami do sterowania innych układów wykonawczych.Nie chcę bronić rozwiązań OC,ale ich siła to soft,hardware to sprawa drugorzędna (tak mi się wydaje).Jeśli przeciętny użytkownik potrafi napisać skrypty w SIOC ta dobrze świadczy o programie.
Jeszcze jedna uwaga co do ich rozwiązań.Mają pakiety,które pracują autonomicznie np.USB LCD.
Obserwuję na viperpits,że tworzą system otwarty to co sugeruje Damos ale pod PHCC w języku C++
http://www.viperpits.org/smf/index.php?topic=3962.0
Nie wchodziłem w szczegóły,ale hardware jest podzielone na płytę matkę oraz córki.Programy piszą niektórzy członkowie forum.
Wracając do naszego podwórka,czy nie można na początek zrobić jeden moduł do sterowania jednego lub paru HD44780 ale komunikującego się z pc przez USB.Można oczywiście pomyśleć także o sterowaniu LED czy 7-seg.przy wykorzystaniu tego samego sterownika lub zaprojektować nowy tak jak to robią w OC.
Przykład prostego rozwiązania to G15 Viper (soft).Jest możliwość wyboru DED lub PFL gdzie sterownik komunikuje się z pc przez USB.Sterownik oraz soft jest tylko do wyświetlania tych parametrów.Podobnie można zrobić dla FS.Jest to tzw.dekompozycja projektowania,czyli proste funkcjonalne moduły(podobnie robi OC).
Pytanie dla nas czy jesteśmy w stanie zrobić projekt kompleksowy,czy raczej na początek zrobić moduł do sterowania kilkoma LCD?
ps
zauważyłem post Damosa i odpowiadam.Damos już o tym kiedyś pisał projektowanie to wiedza oraz dosyć drogi sprzęt.Możemy ten projet potraktować jako zabawę lub hobby,dlatego sugeruję zrobienie prostego modułu opartego na USB i zobaczymy co z tego wyniknie.Jeśli ktoś poważnie myśli o zrobieniu kokpitu to trzeba szukać gotowych rozwiązań.Natomiast ma to sens jeśli robimy tylko panele a nie cały kokpit.
-
Przyznaję, że mam niewielka wiedzę z zakresu interakcji z symulatorami innymi niż LockOn. To budzi pewne obawy odnośnie poprawności zdefiniowanych protokołów i interface'ów.
To IMHO zupełnie inna sprawa. Ja także nie mam pojęcia o innych simach niż Falcon. Głównym problemem byłoby napisanie API do obsługi wyświetlaczy LCD (alfanumerycznych i graficznych) czy też segmentowych. Potem każdy mógłby je zastosować do swoich potrzeb.
I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej :) Mnie bardziej bawi tworzenie więc dla mnie to nie problem. A dla was?
Jako że programuję czysto hobbystycznie to dla mnie również to nie problem. Nie ukrywam, bardziej pociąga mnie korzystanie z efektów własnej pracy, nie cudzej ;)
-
Witam,
cytat Damos
I ostatnia rzecz: możemy być na 90% pewni, że ktoś już to zrobił. Może lepiej, może i taniej
Jest to prawda już to zrobiono i na pewno jest to kontynuowane.Jest na naszym forum od miesiąca nowy kolega,który ma największe doświadczenie w dziedzinie budowy kokpitów.Kończy realizację kokpitu dla A320 oraz rozpoczął budowę kokpitu dla Falcona.Mam nadzieję,że włączy się do dyskusji.
Wracając do pytania co chcemy zrealizować to powiem tak to co jest realne.Dla prostego panelu wystarczy MJoy oraz sterowanie kilkoma LED,7-seg oraz 2,3 LCD.I to można zrobić amatorsko w stosunkowo krótkim czasie.Projekty kokpitów to już inna bajka.
Kokpit Falona to już kilkadziesiąt przycisków,przełączników wyświetlaczy LED, wyświetlacze graficzne LCD oraz MFD,Pozostałe wskaźniki można także zrealizować na LCD 3.4",10.4","8". Aby to uruchomić to trzeba kilku niezależnych programów.Jest to przykład korzystania z gotowych rozwiązań.
Chcąc zrealizować w sensownym czasie jakiś projekt to oprócz założeń technicznych ważny jest czas.Po drugie trzeba wykorzystać zasoby,które są dostępne.W naszym przypadku dotyczy to głównie programistów.Wyspecjalizowanie się w projektowaniu uP w C++ to nie tylko znajomość języka,ale także znajomość stuktury procesora (manuale to powyżej 200str).Aby zrobić efektywny program to trzeba mieć praktykę w tworzeniu algorytmów.
Do czego zmierzam, należy programować w tym języku,który znacie oraz projektować na uP,które także znacie.
Co do mnie o jestem zwolennikiem budowy sterownika dla HD44780 z interfejsem USB.Dlaczego,odpowiedź jest prosta.Zakup wskaźnika DED na viperpits wymaga sporej gotówki,podobnie jest z projektem opartym na klawiaturze Logitech G15.
Jeśli jest potrzebne wsparcie w postaci zapytania o jakiś szczegół dotyczący projektu dla falcona to mogę zapytać na forum viperpits.
-
Uzupełnienie do ostatniego post.
Przejrzałem schemat karty USB LCD z OC i muszę stwierdzić,że zrobili bardzo dobry projekt.Karta jest zrobiona z uP 16C745 z wbudowanym USB oraz 2 buforami 74HC541.Można sterować 4 HD44780 multipleksując linie E.OC udostępnia kod wynikowy i można robiąc deasemblację zobaczyć jak zrobiono program z poziomu asemblera.Zapytałem kolegę czy jest wsparcie programowe dla PIC i otrzymałem odpowiedź
Microchip daje kompletne darmowe zintegrowane środowisko dla programowania w asemblerze. Jest to MPLAB:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002
edytor, assembler, debuger, symulator itd. Można dokupić do tego np. kompilatory C. Można też programować kości, jeśli programator jest kompatybilny z MPLABem.
Fajne jest to, że większość programów można napisać i uruchomić (za symulować) zanim jeszcze powstanie hardware
Ponieważ nikt z forum nie zna PIC to pozostają inne uP oraz programowanie z poziomu C++.Można zrobić podobny projekt z sprzętowym interfejsem USB.Co wy na to?
-
Spróbuję z software'owym interface'm USB an ATmega16... Najtańszy wariant. Jednak jakieś wyniki najwcześniej po weekendzie. To będzie tylko proof-of-concept. Docelowo też myślałem o kluczowaniu po linii E i sterowaniu kilku LCD równocześnie przez bufor :)
-
Dzięki Damos jest nadzieja,że temat będzie rozwijany.Gdyby się udało zrealizować USB na ATmega16 byłoby super.Projekt byłby podobny do OC,ale na znanym uP.Trzymam kciuki
pozdrawiam,vito_zm
-
To wypali pod warunkiem, że HD44780 jest odporny na chwilowe przerwy w komunikacji. Jeśli przyjdzie coś z USB podczas zapisu do wyświetlacza - zapis zostanie na chwilę wstrzymany. Jeśli to nie problem - jest szansa. Może ktoś ma doświadczenie z timingiem tego display'a ?
-
Rozumiem,że chodzi o to,że jeśli podczas zapisu będzie przerwanie od USB to zapis może być "zakłócony" ze względu na priorytet przerwania.Jeśli o to chodzi to jest prosta metoda zrobienia bufora albo wew.uP,albo na zew.z zapisem zboczem.Do zapisu zew.bufora potrzeba dla układów HT kilka ns.Nie wiem czy dobrze zrozumiałem pytanie.
W rozwiązaniu OC dane do HD44780 są brane prosto z portu uP.Nie wiem jak często są odświeżane 4 LCD w ich rozwiązaniu.
-
To nie jest stricte "zakłócenie" a jedynie wstrzymanie wykonywania kodu. Po prostu - czasem przerwy w wysyłaniu danych do wyświetlacza mogą być dłuższe niż wynikało by to z kodu. Jeśli protokół przewiduje ustawienie danych na odpowiednich liniach i zatrzaśnięcie ich chwilowym stanem niskim/wysokim na innej linii, to nie będzie gwarancji maksymalnego czasu miedzy kolejnymi strobe'ami. Nie będzie problemu z zawartością wysyłanych danych. Jeśli protokół nie jest "time critical" to nie będzie problemu.
-
Witam,
kiedyś zapytałem twórcę programu FAST,który pośredniczy pomiędzy Falconem a SIOC wykorzystując rozwiązanie OC podobne do naszego
mihi4 you wrote in your manual about DED and PFL.I mean it is possible
to use FAST to control them but which hardware should I use?
greetings,vito_zm
odpowiedź
Yes, the data is there. But since the IOCProtocol works with changing stats
of variables, other than continuously updated data, it doesn't work very
well without some programming knowledge. For a working and simple DED/PFL
solution I would recommend Airdance's G15/Z10 solution
Może ta odpowiedź coś Tobie podpowie.Ja się domyślam,że te problemy wynikały może z tego,że SIOC reaguje na zdarzenia tzn.porównuje zapisane stany w pamięci współdzielonej (share memory w Falconie) w czasie cyklicznego jej sprawdzania.Jeśli nastąpiła zmiana to wysyła dane na peryferial,jeśli nie to dane pozostają bez zmian.HD44780 musi mieć co jakiś czas odświeżanie jeśli pracuje w opcji multipleksowania.Może to był powód problemów mihi4.
Myślę,że testy Gerrah mogą odpowiedzieć na te wątpliwości,chociaż warunki są inne,ponieważ nie ma multipleksowania LCD.
-
U mnie właśnie dane do LCD są wysyłane tylko jeśli zmienił się stan zmiennych w pamięci współdzielonej (co 50ms). Odświeżać wyświetlacza w moim przypadku nie muszę. Raz zapisane dane w pamięci kontrolera są wyświetlane aż do odłączenia zasilania lub wysłania innego rozkazu.
-
Jest to dobra wiadomość.Czy możesz potwierdzić,że Twój program przepytuje co 50 ms dane (PFL) w RAM pod adresem gdzie są zapisane i jeśli się zmieniły to wysyłasz je do kontrolera?Tak działa SIOC,reaguje na zmiany.Jeśli Damos zaprogramuje USB w uP to mamy prawdopodobnie rozwiązanie podobne do OC.
Problem odświeżania będzie aktualny gdy będzie multipleksowanie np.4 LCD,ale to można rozwiązać.
ps
Co do USB w uP to czy nie można zrobić deasemblacji programu wynikowego MJoya i zobaczyć jak to rozwiązano?Nie wiem jak wygląda sprawa praw autorskich?
-
Raz zapisane dane w pamięci kontrolera są wyświetlane aż do odłączenia zasilania lub wysłania innego rozkazu.
I to jest logiczne - po to jest kontroler "on-board" aby zapamiętać wprowadzony tekst.
Gerrah - możesz zrobić kilka eksperymentów i wpakować jakieś duże delay'e do procedury przesyłającej dane do wyświetlacza ? Jeśli kontroler display'a czeka do skutku na kolejne dane (nie ma timeout'a) - to jesteśmy dużo bliżej :)
Problem odświeżania będzie aktualny gdy będzie multipleksowanie np.4 LCD,ale to można rozwiązać.
Nawet wtedy nie bedziemy mieć problemu z odświeżaniem. :)
Co do USB w uP to czy nie można zrobić deasemblacji programu wynikowego MJoya i zobaczyć jak to rozwiązano?
Nie.... Mam źródła, widziałem stack USB z MJoya i skłaniam się ku innemu rozwiązaniu :) Cierpliwości...
-
Nie wiem co masz na myśli przez "duże delay", ale 1000s nie robi na nim wrażenia. Gorzej jeśli w tym czasie zostanie coś innego przesłane. Jak łatwo się domyśleć "oczekujący" znak nie zostanie wyświetlony.
-
Witam
Trochę kombinuje z OC na płytkach uniwersalnych pod FSX
Jakoś to wyglądało do momentu zerwania kontaktu z posiadaczem programatora do mikro-kontrolerów a na wydatek +100zł mnie na dzień dzisiejszy nie stać.
-
Nie wiem co masz na myśli przez "duże delay", ale 1000s nie robi na nim wrażenia.
No to jestesmy w domu :) Myślałem o delay'u rzędu 10-100 ms. :) W niektórych kontrolerach masz ograniczoną ilość czasu pomiędzy kolejnymi transferami danych. Np. karty chipowe wymagają podawania danych z zegarem nie mniejszym niż ustalony w dokumentacji (np. 1 MHz). Jeśli na chwile wstrzymasz transmisję to tracisz synchronizację i musisz nawiązywać połączenie na nowo...
Gorzej jeśli w tym czasie zostanie coś innego przesłane.
To absolutnie nie będzie miało miejsca.
-
Muszę tylko ostrzec, że u mnie LCD działa na kontrolerze KS0066U. Niby jest zgodny ze standardem HD44870, ale nigdy nic nie wiadomo.
-
spox, damy radę. Ja tez mam inny - kompatybilny (podobno) :)
-
Witam,
kiedy Ty śpisz Damos?
W niektórych kontrolerach masz ograniczoną ilość czasu pomiędzy kolejnymi transferami danych.
Poczytałem trochę na temat kontrolera HD44780 i nie znalazłem informacji na ten temat wynika z tego,że nie ma ograniczeń.Wspominacie o innych kontrolerach.Znalazłem opis procedur dla KS0108 może komuś się przyda http://radzio.dxp.pl/ks0108/
Uświadomiłem sobie przy okazji czytania opisu HD44780 z problemów jakie będą przy odczycie RAM dla DED Falcona.Co do odczytu PFL to nie powinno być problemu (tak myślę).PFL daje tylko komunikaty czyli przy zmianie komunikatu można przesłać nowy komunikat.DED jest interaktywny czyli możemy wpisywać w określone miejsce w określonej lini dane (znaki).W związku z czym program musi przesłać dane do określonego miejsca w danej lini,ale jest to problem na przyszłość gdy powstawną konkretne aplikacje.
-
Po obejrzeniu tego filmiku; http://www.mikesteven.pwp.blueyonder.co.uk/blackshark/blackshark_touchbuddy_2.avi
doszedłem do wniosku że budowa kokpitu stricte pod F16 jest jest pomysłem krótkowzrocznym.
No chyba że ktoś ma tyle funduszy i miejsca że jest w stanie zrobić kilka kokpitów lub też chce latać F16 i niczym innym.
-
Vitam ! Mam już komunikację między PC a ATmega16 po USB. Teraz "tylko" dorzucić obsługę wyświetlaczy, jakiś interface po stronie PC i gotowe... :)
-
Gratulacje Damos,jesteś jak zwykle niezawodny.
Teraz "tylko" dorzucić obsługę wyświetlaczy
Codeking i Gerrah już to zrobili.Codeking z poziomu uP Gerrah pc.Myślę,że jest moment na przejście na ATmega16 ze względu na USB.Z tego co wiem to można procedurę obsługi wyświetlacza napisać w C++,zrobić kompilację oraz połączyć z programem Damosa.Trzeba też ustalić jaki stosujemy wyświetlacz ile linii oraz znaków (oparty na kontrolerze HD44780).Nie jestem pewien czy przy ustalaniu konkretnego wyświetlacza nie pojawią się problemy z uniwersalnością jego zastosowania.Mam na myśli np.PFL gdzie potrzeba tylko2 linie oraz FS gdzie być może potrzeba więcej linii.Pytanie jest następujące,czy wybór konkretnej aplikacji (falcon,FS)jest z poziomu menu PC czy są to oddzielne programy a raczej procedury
jakiś interface po stronie PC ...
W tym punkcie można chyba stworzyć jakiś wspólny protokół komunikacyjny pc USB nie zależnie od aplikacji.Nie mam pojęcia jak pobierać dane dla FS.Co do falcona to Gerrah już to robi,tzn.zna adresy gdzie są dane.
Ja próbuję od pewnego czasu uzyskać informację na ten temat a konkretnie o tzw.Share memory z viperpits,ale bezskutecznie.Pytam w dalszym ciągu.
Teraz wszystko w rękach programistów.Może warto poprosić innych np.Some1 o pomoc.Z mojej strony deklaruję pomoc na poziomie hardware,ale to niewiele.Mogę zrobić prototyp i go testować jeśli to pomoże.
-
Wielkością wyświetlacza nie zawracałbym sobie głowy, to nie ma większego znaczenia. Bardziej przejmowałbym się czy ma być wykorzystywany interfejs 4 bit czy 8 bit.
Vito_zm, co do pamięci współdzielonej to później dokładniej przyjrzę się tamtej bibliotece co podałeś. Co prawda z DED i PFL w tej chwili nie ma problemu, ale chciałbym móc wyciągnąć resztę danych.
-
Wydaje się,że w 8 bitowym wariancie można w przyszłości multipleksować linią E kilka wyświetlaczy.Linia RW może być ustawiona na stałe na zapis tak jak jest w wariancie 4 bit.
ps
Gerrah witam na forum viperpits
-
Z tego co wiem to można procedurę obsługi wyświetlacza napisać w C++,zrobić kompilację oraz połączyć z programem Damosa.
Gdyby to było takie proste... :) Teraz muszę dodać support dla wyświetlaczy w uP. Będzie to wymagało przerobienia sterowników do HD44780. Kodu sterującego HD44780 jest całą masa. Problem polega na tym, że pojawiły się nowe ograniczenia odnośnie obsługi USB :( Kontroler (uP) musi robić tzw. polling (czyli cykliczne odpytywanie) USB z pewnym maksymalnym interwałem czasowym. To będzie wymagało wywoływania obsługi USB z wnętrza kodu obsługującego wyświetlacze. To będzie roboty na minimum 24godziny kodowania.
Trzeba też ustalić jaki stosujemy wyświetlacz ile linii oraz znaków (oparty na kontrolerze HD44780).
To będzie mogło być konfigurowalne.
Nie jestem pewien czy przy ustalaniu konkretnego wyświetlacza nie pojawią się problemy z uniwersalnością jego zastosowania.Mam na myśli np.PFL gdzie potrzeba tylko2 linie oraz FS gdzie być może potrzeba więcej linii.
Na razie tylko HD44780. Dla innych wyświetlaczy trzeba będzie zmienić firmware (oprogramowanie uP).
Pytanie jest następujące,czy wybór konkretnej aplikacji (falcon,FS)jest z poziomu menu PC czy są to oddzielne programy a raczej procedury
Po stronie PC jest moduł, który udaje virtualny wyświetlacz. Dowolna inna aplikacja ustawia na nim tekst a on juz zajmie się przesłaniem tego do fizycznego wyświetlacza. Nasze rozwiązanie nie będzie zależeć od konkretnego symulatora.
W tym punkcie można chyba stworzyć jakiś wspólny protokół komunikacyjny pc USB nie zależnie od aplikacji.
Nie. Można zrobić protokół komunikacji z aplikacją, a inne moduły nawet nie mogą mieć pojęcia, że sprzęt jest podłączony przez USB. Ze względu na ograniczenia sprzętu protokół USB zależy tylko i wyłącznie od możliwości sprzętu.
Nie mam pojęcia jak pobierać dane dla FS.Co do falcona to Gerrah już to robi,tzn.zna adresy gdzie są dane.
A to jest inny problem.
Z mojej strony deklaruję pomoc na poziomie hardware,ale to niewiele.Mogę zrobić prototyp i go testować jeśli to pomoże.
Z pewnością będzie to pomocne.
-
To będzie wymagało wywoływania obsługi USB z wnętrza kodu obsługującego wyświetlacze. To będzie roboty na minimum 24godziny kodowania.
Jako laik zadam trywialne pytanie,czy nie lepiej zastosować wyspecjalizowany układ realizujący USB zamiast tworzyć jego emulację w uP.Czy to rozwiązanie uprościłoby w znaczący sposób programowanie?
Druga sprawa to łączenie programów pisanych przez kilku programistów.Z tego co pamiętam z mojej pracy zawodowej to pisaliśmy procedury w języku PL a później w Paskalu i tworzyliśmy biblioteki.Każdy kto programował swój uP z nich korzystał.Ten sposób programowania był dosyć efektywny.O tym myślałem aby każdy programista napisał swój moduł lub procedurę,nie jestem pewien czy w naszym przypadku jest to możliwe.
-
Jako laik zadam trywialne pytanie,czy nie lepiej zastosować wyspecjalizowany układ realizujący USB zamiast tworzyć jego emulację w uP.Czy to rozwiązanie uprościłoby w znaczący sposób programowanie?
I tak i nie :) Po pierwsze - jestem(śmy) ograniczony do Atmeli. W rodzinie Atmela praktycznie tylko dwa układy zasługują na uwagę: AT90USB oraz AT32UC3(B). Pierwszy jest dwa razy droższy od Atmega16, ma sprzętowe USB z którym i tak trzeba się narobić i do tego tą sama szybkość co Atmega16 a obudowę trudniejszą do lutowania (tylko SMD: TQFP48). Drugi to 32-bitowa kość nowej generacji, obsługiwana innym kompilatorem, z innym API. Posiada USB i jest kilkukrotnie szybsza od ATmegi, ale też dwukrotnie droższa. Ma sprzętowe USB, może pracować nawet jako host USB. Obudowa jeszcze bardziej hardcore'owa: TQFP64 lub TQFP100 :) Gabarytowo zaś jest mniejsza od wszystkich za wyjątkiem ATiny :) Oczywistym wyborem jest w miarę tania kość z dużymi możliwościami. Powinno dać się na niej (jednej) zrobić wyświetlacze, enkodery, sterowniki diod, dodatkowe klawisze etc.
http://www.atmel.com/dyn/resources/prod_documents/doc32059.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf
Ale to jest dłuższa robota. Nad ATmega usiadłem na kilka godzin i jest efekt. Na AT32UC3B potrzebuję kilku tygodni. Ponad 1000 stron dokumentacji :)
Druga sprawa to łączenie programów pisanych przez kilku programistów.Z tego co pamiętam z mojej pracy zawodowej to pisaliśmy procedury w języku PL a później w Paskalu i tworzyliśmy biblioteki.Każdy kto programował swój uP z nich korzystał.Ten sposób programowania był dosyć efektywny.
U nas tylko jedna osoba programuje uP :) Ja mogę przyjąć biblioteki dla AVRGCC.
-
Czyli sprawa jest wyjaśniona.Jeśli coś chcemy robić to na tym na czym się znamy.Teraz pytanie ogólne czy jesteśmy w stanie określić moduły programowe lub raczej procedury tak aby po uzgodnieniu danych wejściowych i wyjściowych (tak to się chyba nazywa w programowaniu obiektowym) można było je pisać.Chodzi o to,żeby odciążyć Damosa.Zdaję sobie sprawę,że programowanie pod konkretny uP wymaga jego znajomości,ale z tego co wiem z tym nie powinno być problemu.
-
Mi, jakby co, należy wskazać co i w czym a ja już postaram się aby zostało to jak najszybciej i w miarę bezbugowo zrealizowane :)
Szkoda, że na USB się kompletnie nie znam :( Każdorazowo po wpisaniu w google "usb documentation" dostaję dreszczy i pot mi się skrapla na czole ;)
-
Każdorazowo po wpisaniu w google "usb documentation" dostaję dreszczy i pot mi się skrapla na czole
Myślę,że z tym nie będzie problemu ponieważ Damos to już rozwiązał.Ponieważ jest on zawodowym programistą i ma największe z nas doświadczenie w programowaniu i nie tylko to on zadecyduje o dalszej współpracy i podziale zadań.
-
Panowie, jak tak sobie śledzę ten wątek i czytam co tu piszecie w niezrozumiałym dla mnie języku :), to mam wizję, że jak już się Wam uda doprowadzić ten projekt do końca, to szkoda by Wasz trud i wiedzę marnować na "jednorazowy" użytek.
Jak będą efekty (np. w postaci możliwości wyświetlania MFD z Falcona [takie śmiałe marzenie :D ] ) to powinniście poważnie zastanowić się nad ścisłą współpracą, z założeniem firmy, produkcją i dystrybucją tego rozwiązania, co jak sądzę znalazłoby zbyt nie tylko wśród chłopaków z 13-ej, ale w całym światku Falcona.
Z taką wizją w główce, pozdrawiam, trzymam za Was kciuki, życzę powodzenia w realizacji i nie wcinam się już w temat ;)
-
Jak będą efekty (np. w postaci możliwości wyświetlania MFD z Falcona [takie śmiałe marzenie
To już jest zrobione i dostępne za free.Za tydzień dostanę nowy pc to rozpocznę testy z MFD.Napiszę o tym dokładnie w swoim wątku.
-
Jeżeli chodzi o współpracę tego układu z FS-em a dokładnie poprzez dodatek FSUIPC to znalazłem coś takiego - http://www.schiratti.com/files/dowson/FSUIPC_SDK.zip?timestamp=010309 - może się przydać przy pisaniu programu / dla mnie to czarna magia :015: /, ale jak będę mógł pomóc np. przy pcb to natychmiast.
pozdrawiam Zając
-
ale jak będę mógł pomóc np. przy pcb to natychmiast
Jestem pewien,że będziesz potrzeby w tym temacie.Gdy powstanie schemat sterownika to uzgodnimy szczegóły.
-
Ok czekam na wieści :001:
Zając
-
Jest pewien progress - mam kod obsługujący za pomocą ATmega16 maksymalnie 21 wyświetlaczy alfanumerycznych zgodnych z HD44780 - wystarczy tyle ? ;) (można by 25 przy 4-ro bitowym protokole, ale będzie wolniejsze ze względu na protokół.). Prawdopodobnie trzeba będzie dodać jakiś bufor magistrali, aby mógł prądowo obsłużyć 21 odbiorników (wyświetlaczy), ale to nie problem. Dojdą 3 dość tanie układy scalone.
Czy ktoś z kolegów ma kilka wyświetlaczy i możliwość zbudowania układu prototypowego? Pewnie vito_zm byłby najlepszym kandydatem :)
Teraz muszę jedynie zdefiniować protokół przez warstwę transportu USB, obsłużyć go (to raczej prosty task), zrobić sterownik na PC i będzie gotowe do normalnych testów.
-
Pierwsza wersja gotowa:
- protokół USB zdefiniowany
- obsłużony w urządzeniu
- obsłużony na PC
- prosta aplikacja testowa gotowa i przetestowana
- wykonany test na każdym z 21 wyświetlaczy (oczywiście - za każdym razem ten sam, tylko podpinany pod inne sterowanie :) )
teraz zostało najtrudniejsze: zrobić schemat i wysłać do vito_zm w celu wykonania niezależnego testu :)
-
Miałem problemy z komunikacją z forum,dlatego tak późno wysyłam post.Gratulacje Damos,podeślij mi szkic schematu.Ile potrzebujesz wyświetlaczy i ile wyświetlanych linii.Postaram się kupić w sklepie elementy i zrobię model na płycie uniwersalnej.
-
Wysłaliśmy post w tym samym czasie.Zrób odręczny szkic oraz jego zdjęcie i prześlij jako załącznik.
Jeszcze raz gratuluję i życzę miłego snu.
-
ok, schemat jest tu:
http://www.damos.k11.pl/LO/lcd_avr/ATMega16_USB_LCD.png
wsad do ATMega16 tu:
http://www.damos.k11.pl/LO/lcd_avr/dm_firmware.hex
(uwaga - zegar 16MHz więc CKOPT)
aplikacja testowa tu:
http://www.damos.k11.pl/LO/lcd_avr/TestApp.exe
i sterowniki do USB, które należy zainstalować tu:
http://www.damos.k11.pl/LO/lcd_avr/libusb-win32-filter-bin-0.1.12.1.exe
Dobrze by było zobaczyć, czy program odpali się bez instalacji sterowników, jedynie z użyciem dll'a:
http://www.damos.k11.pl/LO/lcd_avr/libusb0.dll
Teraz kilka słów objaśnień.
1 - schemat
- przycisk RESET nie jest konieczny :)
- rezystor R3 (1M) nie jest konieczny -dałem go, żeby mi D+ nie pływało - tak na wszelki wypadek
- diody D1 i D2 MUSZĄ być diodami zenera na 3,3V
- R1 i R2 powinny mieć 68 ohm, ja miałem tylko 100 ohm i działa bez problemu
- C1 i C4 (elektrolit + ceramiczny) nie są konieczne, lecz dałem je na wszelki wypadek, aby nie mieć problemów z zakłóceniami. Należy je umieścić jak najbliżej IC1
- uwaga na linie z USB: D+ i D-, nie można ich zamieniać. D+ musi być podłączona do PD2, a D- do PD4. Po płytce MJoy'a można dojść, które wyjścia z gniazda USB są które: D- jest podciągana rezystorem 1K5 do plusa.
- IC2 i IC3 - nie podłączałem ich, jako, że mam tylko jeden wyświetlacz - sterowałem go bezpośrednio z portów uP
- LCD1 - LCD21, to symbolicznie pokazane złącza na wyświetlaczach. Jak widać większość linii jest połączona równolegle (współdzielona), za wyjątkiem pinu nr 6 (linia "E"), który jest odpowiedzialny za "selekcję" wyświetlacza, który ma w danym momencie odbierać dane. Potencjometr jest przykładowo, ja mam chyba 3 kilowy rezystor - zależy od wyświetlacza. Złącze na górze ekranu jest czysto symboliczne i pokazuje do których pinów uP należy podłączać linie "E" kolejnych wyświetlaczy. Oszczędziłem sobie dzięki temu umieszczania na schemacie kolejnych 19-tu złączy LCD... Kolejność jest następująca: pierwszych 8 LCD do PA0-PA7, następne 8 do PB0-PB7, ostatnie 5 to PD0,PD1,PD3,PD5,PD6.
Zasilanie... nie wiem, czy USB "pociągnie" 21 LCD - prawdopodobnie nie. Dlatego umieściłem osobne VCC. Jednak ja zasilałem układ z USB :P
2 - drivery:
- załączyłem instalkę lib-usb. Teoretycznie aplikacja testowa może działać bez tej instalacji, wymaga jedynie obecności załączonego dll'a. Nie testowałem jeszcze tego wariantu.
3 - program w uP:
obsługuje 21 wyświetlaczy zgodnych z HD44780. Jak się okazuje, z tą zgodnością różnie bywa. Mój wyświetlacz obsługuje tryb 2 linii.... w ten sposób, że każda linia ma 8 znaków i są umieszczone jedna za drugą w ... jednej linii :) ! Bo sam wyświetlacz pokazuje jedynie jeden wiersz tekstu. I jest to zgodne z HD44780. Nie testowałem kodu na wyświetlaczu 4-ro liniowym ani prawdziwie - 2 liniowym, z 40-toma znakami na linię (bo takich nie posiadam). Nie mam supportu (na razie ?) dla wyświetlaczy z dwiema liniami "E". Oprogramowanie na razie nie supportuje scrollowania okna ani zapisywania własnych fontów, ale to drugie jest w planie :) Jeśli chodzi o USB, to korzystam jedynie z transmisji kontrolnych (usb_control_msg) a nie z raportów HID. Tak więc nie ma sensu podłączać się do tego "Generic Hid Testerem".
4 - program na PC:
jest to prosty, testowy programik zawierający combo-box'a oraz 4 pola edycyjne. Za pomoca combo wybierasz nr wyswietlacza (od 0 do 20) a w polach tekstowych wpisujesz tekst, który pojawia się na wyświetlaczu. W moim przypadku, przy podłączeniu linii E wyświetlacza do PA0 (nóżka nr 40), wybieram na combo "LCD0" i następnie w "Line0" wpisuję pierwsze 8 znaków a w "Line1" kolejne 8 znaków. W ten sposób zapełniam wyświetlacz (16 znaków). I faktycznie na takim działaniu ma polegać testowanie :) Oczywiście - przedtem należy podłączyć układ do USB ! :)
Gdyby program nie odpalał się z braku dll'i typu MSVCRT*.* czy podobnych, daj znać, wtedy je dorzucę (jednak jest prawdopodobne, że już je masz). Naturalnie - finalny interface będzie zupełnie inny ! :)
To chyba wszystko, co przychodzi mi teraz do głowy.... w razie pytań - nie krępować się :)
-
Dzięki Damos za dokumentację.Przystępuję do działania.Będę informował o wynikach.
-
ok, schemat jest tu:
http://www.damos.k11.pl/LO/lcd_avr/ATMega16_USB_LCD.png
Czy te ULN'y są naprawdę konieczne ? Prąd na wyjściach uP do wyświetlaczy idzie tylko gdy trzeba wysłać jakiś rozkaz, no i nie musi on być szczególnie duży. Jeśli się mylę to proszę o poprawkę.
aplikacja testowa tu:
http://www.damos.k11.pl/LO/lcd_avr/TestApp.exe
Jakiego interfejsu można się spodziewać ? Z mojego punktu widzenia najlepsza byłaby statyczna biblioteka z funkcjami (wyeksportowanymi) do obsługi wyświetlaczy. Nie wiem jakie przewidujesz metody, w moim prostym rozwiązaniu były praktycznie dwie główne: czyść ekran i pisz znak C na X i Y. Metodę czyść można zrealizować tą drugą ale HD44780 ma rozkaz Clear i działa on w tym przypadku szybciej. Pytam o to, bo chciałbym dodać obsługę tych wyświetlaczy do swojego programu. A w C# wystarczy znać deklarację metod i po sprawie (nie lubię gdy na komputerach zwykłych użytkowników trzeba rejestrować jakieś biblioteki (ActiveX itp.)).
Dobrze by było zobaczyć, czy program odpali się bez instalacji sterowników, jedynie z użyciem dll'a:
http://www.damos.k11.pl/LO/lcd_avr/libusb0.dll
Byłoby super gdyby nie trzeba było instalować sterowników, w końcu do HID.
Zasilanie... nie wiem, czy USB "pociągnie" 21 LCD - prawdopodobnie nie. Dlatego umieściłem osobne VCC. Jednak ja zasilałem układ z USB :P
Czy tryb USB, który daje 500mA nie da rady ? Nie wiem ile taki wyświetlacz potrzebuje, chociaż licząc samo podświetlenie wyświetlaczy to może dać kilkaset mA. Fajnie gdy nie był potrzebny zewnętrzny zasilacz, aczkolwiek to sprawa mało istotna.
3 - program w uP:
obsługuje 21 wyświetlaczy zgodnych z HD44780. Jak się okazuje, z tą zgodnością różnie bywa. Mój wyświetlacz obsługuje tryb 2 linii.... w ten sposób, że każda linia ma 8 znaków i są umieszczone jedna za drugą w ... jednej linii :) ! Bo sam wyświetlacz pokazuje jedynie jeden wiersz tekstu. I jest to zgodne z HD44780.
Ciekawe :) Kod do obsługi LCD pisałeś sam czy może korzystałeś ze strony http://radzio.dxp.pl/hd44780/ ? Jest tam zaimplementowana metoda coś jak GotoXY, która przesuwa kursor w odpowiednie miejsce. Może to jakoś pomoże.
Nie mam supportu (na razie ?) dla wyświetlaczy z dwiema liniami "E".
Taki wyświetlacz podpina się chyba jako dwa, używając tych samych linii oprócz "E".
Oprogramowanie na razie nie supportuje scrollowania okna ani zapisywania własnych fontów, ale to drugie jest w planie :)
Definiowanie własnych fontów jest OK, co prawda ilość znaków jest ograniczona ale zawsze coś. Co do scrollowania to można to zrzucić na programistów konkretnych aplikacji :)
4 - program na PC:
jest to prosty, testowy programik zawierający combo-box'a oraz 4 pola edycyjne. Za pomoca combo wybierasz nr wyswietlacza (od 0 do 20) a w polach tekstowych wpisujesz tekst, który pojawia się na wyświetlaczu. W moim przypadku, przy podłączeniu linii E wyświetlacza do PA0 (nóżka nr 40), wybieram na combo "LCD0" i następnie w "Line0" wpisuję pierwsze 8 znaków a w "Line1" kolejne 8 znaków. W ten sposób zapełniam wyświetlacz (16 znaków). I faktycznie na takim działaniu ma polegać testowanie :)
Tutaj zapytam o to co wspomniałem wcześniej: czy będzie możliwość pisania znaku na wybranej pozycji X, Y ?
-
Czy te ULN'y są naprawdę konieczne ? Prąd na wyjściach uP do wyświetlaczy idzie tylko gdy trzeba wysłać jakiś rozkaz, no i nie musi on być szczególnie duży. Jeśli się mylę to proszę o poprawkę.
Na szynie danych WSZYSTKIE wyświetlacze pobierają prąd. Maksymalne obciążenie jednego portu w ATMega to 40 mA. Przy 21 wyświetlaczach daje to 1.9 mA na LCD. To przemnożone przez ilość odbiorników daje peek minimalnie poniżej 360 mA - czylu USB jeszcze dycha... Jak jeden pin pobierze więcej - mamy kłopoty - z dymem idzie ATMega.
Jakiego interfejsu można się spodziewać ? Z mojego punktu widzenia najlepsza byłaby statyczna biblioteka z funkcjami (wyeksportowanymi) do obsługi wyświetlaczy.
STATYCZNA ? Przypominam, ze ja piszę w C++. Chcesz do C# linkować lib'a z C++? Z tego, co wiem - to nie wypali. Lepiej już biblioteka dynamiczna (*.dll). Jednak osobiście skłaniam się serwisowi/samodzielnej aplikacji , która będzie komunikować się "ze światem" po TCP i (ewentualnie) named pipes. Będzie też mieć wbudowany własny mini-serwer WWW do konfiguracji i testowania wyświetlaczy. Oczywiście - w przyszłości będzie mogła kontrolować więcej rzeczy niż tylko wyświetlacze.
Nie wiem jakie przewidujesz metody, w moim prostym rozwiązaniu były praktycznie dwie główne: czyść ekran i pisz znak C na X i Y.
Układ ma reprezentować 21 "virtualnych" wyświetlaczy LCD z płaskim adresowaniem linii. Wysyłasz komendę wyczyszczenia lub ustawienia tekstu podając wiersz i kolumnę oraz ciąg znaków do wpisania. Program sam ustala, jaki tekst uległ zmianie i co wysłać przez USB i w jaki sposób. Można by pomyśleć również o definiowaniu własnych obszarów wewnątrz wyświetlaczy (identyfikowanych przez ID) i wysyłaniu tekstu do nich. Takie ID obszaru definiowało by jednoznacznie wyświetlacz i zakres znaków na nim. Wtedy wysyłasz jedynie ID obszaru, adres początkowy i string. (zawijanie tekstu wewnątrz obszaru i brak możliwości wyjścia tekstu po za zdefiniowany obszar, indywidualne czyszczenie całego obszaru).
Metodę czyść można zrealizować tą drugą ale HD44780 ma rozkaz Clear i działa on w tym przypadku szybciej.
:) Implementacja tego to jedna z pierwszych rzeczy, jakie zrobiłem. :)
w C# wystarczy znać deklarację metod i po sprawie
Tylko w przypadku DLL'i. Mój Lib ci nic nie da. Ponadto po stronie "sterownika" chcę pamiętać treść wyświetlacza (detekcja zmian, definiowanie obszarów) i wysyłać dane w osobnym wątku (nadawca nie czeka na wysłanie danych do LCD) - więc potrzebuję osobnego procesu.
(nie lubię gdy na komputerach zwykłych użytkowników trzeba rejestrować jakieś biblioteki (ActiveX itp.)).
Apage satanas! Jakie ActiveX'y !?
Byłoby super gdyby nie trzeba było instalować sterowników, w końcu do HID.
Może później. Pisałem, że nie korzystam z raportów HID a jedynie transmisji kontrolnych. Do kompilacji modułu używającego deskryptorów HID muszę mieć DDK. DDK, który jako taki nie jest już dystrybuowany. O DDK trzeba żebrać w M$ o WDK , rejestrować się, ściągać kilkaset MB itd. innego na W2K, XP itd. Dodatkowo to działa tylko na "Wingrozie". Do zrobienia, ale później. Moim celem jest uzyskanie wieloplatformowości, co daje niezwykle prosty w instalacji lib-usb.
Czy tryb USB, który daje 500mA nie da rady ? Nie wiem ile taki wyświetlacz potrzebuje, chociaż licząc samo podświetlenie wyświetlaczy to może dać kilkaset mA. Fajnie gdy nie był potrzebny zewnętrzny zasilacz, aczkolwiek to sprawa mało istotna.
Fajnie by było, ale na jeden wyświetlacz zostaje wtedy jakieś 19 mA. Może wystarczy?
Ciekawe :) Kod do obsługi LCD pisałeś sam czy może korzystałeś ze strony http://radzio.dxp.pl/hd44780/ ? Jest tam zaimplementowana metoda coś jak GotoXY, która przesuwa kursor w odpowiednie miejsce. Może to jakoś pomoże.
Swój kod oparłem na jego kodzie, ale musiałem usunąć bugi w f-cji "_LCD_Write" (złe timingi) i przerobić na obsługę wielu wyświetlaczy. GotoXY to nic innego jak wyliczanie adresu komórki, pod który trafią dane. Używam tego. Tam nie ma żadnej logiki robiącej z 2 linii jedną. Poprostu adres pierwszych 8-miu znaków to 0x00 a adres następnych 8-miu znaków tej samej linii to 0x40.
Taki wyświetlacz podpina się chyba jako dwa, używając tych samych linii oprócz "E".
Najprawdopodobniej masz rację :)
Definiowanie własnych fontów jest OK, co prawda ilość znaków jest ograniczona ale zawsze coś. Co do scrollowania to można to zrzucić na programistów konkretnych aplikacji :)
Też tak uważam.
Tutaj zapytam o to co wspomniałem wcześniej: czy będzie możliwość pisania znaku na wybranej pozycji X, Y ?
Oczywiście, ze tak. Inaczej się nie da. Jeden znak zapiszesz, jeśli wyślesz string o długości 1.
-
Na szynie danych WSZYSTKIE wyświetlacze pobierają prąd.
No chyba że tak.
STATYCZNA ? Przypominam, ze ja piszę w C++. Chcesz do C# linkować lib'a z C++?
Przepraszam, pomyliłem się. Chodzi mi o to aby nie tworzyć biblioteki "rejestrowanej" (COM, ActiveX itp.) tylko zwykłą DLL (jak w WinAPI).
Jednak osobiście skłaniam się serwisowi/samodzielnej aplikacji , która będzie komunikować się "ze światem" po TCP i (ewentualnie) named pipes. Będzie też mieć wbudowany własny mini-serwer WWW do konfiguracji i testowania wyświetlaczy. Oczywiście - w przyszłości będzie mogła kontrolować więcej rzeczy niż tylko wyświetlacze.
Czyli kompleksowe rozwiązanie :) Pozostaje czekać na kolejne urządzenia.
Można by pomyśleć również o definiowaniu własnych obszarów wewnątrz wyświetlaczy (identyfikowanych przez ID) i wysyłaniu tekstu do nich. Takie ID obszaru definiowało by jednoznacznie wyświetlacz i zakres znaków na nim. Wtedy wysyłasz jedynie ID obszaru, adres początkowy i string. (zawijanie tekstu wewnątrz obszaru i brak możliwości wyjścia tekstu po za zdefiniowany obszar, indywidualne czyszczenie całego obszaru).
Taką rzecz zrobiłem u siebie. Można zdefiniować obszar np. trój-znakowy ale każdy znak w zupełnie innym miejscu i z pokręconą kolejnością :)
Apage satanas! Jakie ActiveX'y !?
To była pomyłka (napisałem wyżej).
Wspomniane było wcześniej o obawie timingów przy komunikacji USB przerywającej komunikację z LCD. Czy próbowałeś wykonać test (jakiś testowy programik) polegający na szybkim wysyłaniu różnych tekstów na wyświetlacz (dłuższa seria kilkunastu lub więcej rozkazów wyświetlenia napisów na LCD) i sprawdzeniu czy stan na LCD jest taki jak powinien ?
-
Wspomniane było wcześniej o obawie timingów przy komunikacji USB przerywającej komunikację z LCD. Czy próbowałeś wykonać test (jakiś testowy programik) polegający na szybkim wysyłaniu różnych tekstów na wyświetlacz (dłuższa seria kilkunastu lub więcej rozkazów wyświetlenia napisów na LCD) i sprawdzeniu czy stan na LCD jest taki jak powinien ?
Już wcześniej pisałem, że zaskoczył mnie nieco model pracy stosowanego u mnie stack'a USB (polling). Obecnie każdy request USB jest przetwarzany "w czasie rzeczywistym" i Host czeka na odpowiedź kontrolera. W tym czasie wątek na PC jest idle i czeka na powrót call'a do USB. Między innymi dlatego aplikacja kontrolna będzie pracować na osobnym wątku. uP musi cyklicznie odpytywać USB pod kątem nadchodzących danych/komend. Z tego powodu zmieniłem planowany model głównej pętli softu na uP, która miała cyklicznie update'ować wyświetlacze i być przerywana przez przychodzące z zewnątrz requesty USB. Obecnie update jest wykonywany w obsłudze requesta USB i nie jest niczym przerywany. Robiłem testy z "masowym" wysyłaniem danych do LCD. Aplikacja testowa, którą wystawiłem na WWW liczy średni czas wykonania komendy USB przez wywołanie komendy (wysłanie 16-tu znaków) w pętli 10 razy i pomiar tego czasu. Przedtem było to 100 iteracji - bez problemów. tak więc tamten problem już nie istnieje.
edit:
Apropos ULN2003A:
Można (należało by ?) zrobić test bez nich. Wyniki dostaniesz jedynie dla testowanych egzemplarzy. Jeśli ktoś inny zastosuje kompatybilne układy innego producenta - apetyt na prąd może być większy. Ew w przypadku mniejszej ilości wyświetlaczy - zamiast montować układy na płytce można połączyć ze sobą odpowiednie pary nóżek:
1->16
2->15
3->14
4->13
5->12
6->11
7->10
-
Jutro kończę montaż i rozpoczynam testy.Kupiłem 2 wyświetlacze 2x16 podobno są kompatybilne z HD44780 (tak twierdzą sprzedawcy-zobaczymy).Jeden ma 16 pin w jednym rzędzie,drugi ma 2 rzędy po 7 pin.Mam obawy co do wyprowadzeń tego drugiego (na których pinach są sygnały).Znalazłem stronę gdzie jest tzw.model KFC
http://symlink.dk/electro/hd44780/
Czy ktoś zna może wyprowadzenia tego z 7x2pin?
Co do buforowania to OC dla 4 wyświetlaczy stosuje bufory 74HC541.
-
2 rzędy po 7 pin wygląda jak zwykły interface, tylko pozbawiony LED+ i LED- (15 i 16 styk). Powinno działać. sygnały na pinach o odpowiednich numerach są na linku przedstawionym przez Ciebie. Jak są ułożone numery na wyprowadzeniach? Nie mam pojęcia - może jest "jedynka" na płytce przy pierwszym pinie? Może kwadratowe pole, do którego został przylutowany pierwszy pin?
Co do buforowania, to wrzuciłem kość, która akurat leżała na biurku i OC jej chyba używało :) Jednak zastanawia mnie brak podłączania jej do plusa... Wygląda tak, jakby ona potrafiła jedynie zwierać do masy ? :) Wtedy faktycznie potrzebny jest inny driver.
-
apropos 74HC541:
On ma mniejszy output current niż ATMega :) - ledwie 35 mA per pin ( http://www.datasheetcatalog.org/datasheet/motorola/74HC541.pdf )
Może ktoś zna lepszy driver magistrali ?
-
ULN 2003 jest bardzo dobrym driverem,ma dużą wydajność prądową (mam to w pamięci) mogę jeszcze sprawdzić.Pin 9 musi być na plusie.OC stosuje ten układ w Display II do sterowania 7-seg. LED.
-
Ale czy ULN2003 poda napięcie do LCD ? Prąd popłynie od LCD przez ULN do GND, czy tak ? Stosowałem w ten sposób ULN2803 (większy ULN2003) do matrycy diód LED. Proszę o poprawkę jeśli się mylę - coś się nauczę :)
-
Nie mylisz się.
Układ ULN2003 w aplikacji OC był podłączony do wspólnej katody 7-seg.,czyli anody były podłączone do scalaka HC541,który dawał napięcie przez szeregowy opornik.Dla tej aplikacji układ był doskonały (na wyjściu ULN2003 układ darlingtona zapewniający prąd 500mA.)Dla naszego przypadku musimy znaleźć inny driver.
-
Ale czy ULN2003 poda napięcie do LCD ? Prąd popłynie od LCD przez ULN do GND, czy tak ?
Niestety - masz racje... :( Jak mówiłem - ten ULN umie tylko zwierać do masy. Logicznej jedynki nie poda, chyba, że podciągnie się jego wyjścia, ale to znów jest generowanie dużego poboru mocy.
-
Odpowiednikiem PNP dla ULN2003 jest chyba UDN2981A czy coś podobnego, tylko kosztuje trzykrotnie więcej.
-
Sprawdziłem masz rację jest odpowiedni dla naszego projektu,kosztuje około 6 zł 1szt w TEM,można wyjście drivera obciążyć 500mA.
Trzeba sprawdzić (pomierzyć) ile pobiera wyświetlacz LCD.
-
Sprawdziłem masz rację jest odpowiedni dla naszego projektu,kosztuje około 6 zł 1szt w TEM
w AVT tylko 4 PLN :) Pomierzyłem swój wyświetlacz - wejścia danych pobierają ok -106,7 uA. Tak samo RS. E wydaje się pracować czystko napięciowo ! :) Nie pobiera prądu. Pomiar oczywiście statyczny - bez oscylogramu. Mam czysto amatorskie zabawki :)W takim układzie (teoretycznie) ATMega może obsłużyć duuużo takich wyświetlaczy. USB również. Pobór prądu w stanie spoczynku to 1,34 mA, w czasie wyświetlania całej linii spada do ok 800uA. Może niepotrzebnie się martwimy ? :) Całość (wraz z uP) w czasie pracy pobiera ok 28mA, w peeku do 32,5 mA. Po odłączeniu wyświetlacza pobór spada o ok. 1.3 mA.
-
Wynika z tego,że OC dało bufory profilaktycznie po to aby zrobić separację uP od peryferiali.
Pierwsza próba uruchomienia nieudana,mam komunikat urządzenie nieznane.Teraz czekam na kontakt z Damosem.
-
Znaczy to, ze urządzenie nie obsługuje USB poprawnie. Albo zły zegar (ma być 16MHz), albo źle podpięte piny z gniazda USB (to rozpiska: http://www.damos.k11.pl/LO/lcd_avr/piny_USB.PNG) albo złe diody zenera. Zobaczymy, co jest nie tak :)
-
Już jest o.k.Mój błąd przy montażu.Teraz montaż układu wyświetlacza i testy.
-
A czy da się programować ATMegę poprzez RS232?
-
PonyProg ma wersję równoległą (LPT)oraz szeregową (COM) programowania kości.
-
PonyProg ma wersję równoległą (LPT)oraz szeregową (COM) programowania kości.
Mógłbyś trochę rozwinąć? Np jak podpiąć kość pod RS232?
-
To będzie coś takiego? http://www.captain.at/electronic-atmega16-serial-port.php
Jak skonfigurować PonyProga pod RSa?
-
Witajcie
Jeżeli ktoś nie zna strony to polecam naprawdę ciekawe pomysły dla ciekawych zapaleńców :118: 3 Axis motion platform home made ?? dziwne a jednak możliwe. Udało mi się nawet porozmawiać z tym panem na fsweekend niemniej jednak mówił, że system wymaga wielu przeróbek do najistotniejszych należy modernizacja systemu zasilania poza tym jak byście zobaczyli tę mongolską konstrukcje i to do czego była podpięta, w szczególności home made kontroler to byście się za głowę złapali.
Niemniej jednak śmigało z niejednym ochotnikiem na pokładzie.
http://simprojects.nl/ (http://simprojects.nl/)
-
Witam,
uruchomiłem pierwszy wyświetlacz.Drugi ma inne wyprowadzenia,dlatego muszę zrobić na płycie z uP drugie wyjście 14 pin.W poniedziałek pawinny pracować oba.
Bardzo przyjazny program do testowania,moje gratulacje Damos.Na zdjęciu widać prototyp.Wyświetla jedną linię 16 znaków.
(http://img190.imageshack.us/img190/1759/p1010179b.th.jpg) (http://img190.imageshack.us/i/p1010179b.jpg/)
Mikey81 PonyProg programowo można ustawić na COM lub LPT.Ponieważ na forum wszyscy stosujemy LPT to nikt tego nie analizował.Myślę,że najprościej zaprogramować u znajomego na LPT (na pewno ktoś znajomy ma to wyjście).
-
Dobra robota Vito_zm ! Czyli działanie u mnie nie było przypadkiem ;)
W takim razie spokojnie mogę brać się do dalszych tasków.
-
Zrobiłem test z dwoma wyświetlaczami. Jeden "normalny" a drugi jest w wersji "negative" z podświetleniem.
Wysłałem do obu LCD takie same, dwie linijki tekstu, jak na obrazku:
(http://www.damos.k11.pl/LO/lcd_avr/software.PNG)
w wyniku tego oba displaye pokazały go, ale każdy inaczej:
(http://www.damos.k11.pl/LO/lcd_avr/IMG_3119-3.jpg) (http://www.damos.k11.pl/LO/lcd_avr/IMG_3119.jpg)
Jak widać, pierwszy składa obok siebie dwie 8-mio znakowe linie a drugi jedna pod druga dwie 16-to znakowe.
Jednak interface działa i potrafi kierować odpowiednie teksty do odpowiednich wyświetlaczy:
(http://www.damos.k11.pl/LO/lcd_avr/IMG_3120-1.jpg) (http://www.damos.k11.pl/LO/lcd_avr/IMG_3120-2.jpg)
Zrobiłem też pomiary poboru prądu przez układ z 2-ma wyświetlaczami:
- bez podświetlenia pobór na poziomie 29,7 mA (czyli ok. 1 mA więcej niż układ jedynie z pierwszym LCD)
- w peeku 32,9 mA
- z podświetleniem (w zależności od siły podświetlenia) od 31 mA do 90 mA. Teoretycznie więc podświetlenie może pobierać ok. 3 mA i już dawać efekt.
W takim układzie, przy założeniu średniego prądu na jeden LCD na poziomie 9 mA (faktyczny pobór max 2 mA + zapas 2 mA + podświetlenie 5 mA) można z USB zasilić układ sterujący oraz wszystkie 21 wyświetlaczy :010: :banan (sumaryczny pobierany prąd: 21*9mA + 27mA = 216 mA przy maksymalnym, dopuszczalnym 500 mA )
Z negatywnych obserwacji: każdy z wyświetlaczy wymagał osobnego rezystora sterującego jasnością - połączenie razem wyjść VO w obu LCD do wspólnego rezystora powodowało zanik obrazu. (jednak to są dwie zupełnie odmienne konstrukcje, nie wiem co w przypadku jednakowych)
-
A jak wygląda sprawa z tym nieszczęsnym driver'em ? No i kiedy będzie można spodziewać się zakończenia projektowania układu i rozpoczęcie tworzenia PCB ?
Vo jest od kontrastu, lepiej, żeby każdy wyświetlacz miał swój.
-
A jak wygląda sprawa z tym nieszczęsnym driver'em ?
Biblioteka (bo nie jest to driver dedykowany do konkretnego urządzenia) jest bardzo szczęsna, darmowa, powszechnie dostępna i ma gotowy instalator. Jednorazowa czynność zajmująca minutę. Nie widzę tu problemu. W porównaniu do nieszczęsnego .NET Frameworka ona wręcz nie istnieje :)
No i kiedy będzie można spodziewać się zakończenia projektowania układu i rozpoczęcie tworzenia PCB ?
Układ właściwie jest już zaprojektowany. Części to raptem:
ATmega +
1 rezonator
2 diody
3 rezystory
4 kondensatory.
Wszystko wskazuje na to, że drivery prądowe nie są potrzebne.
IMO już można pracować nad PCB. Jedyną kwestią jest postać złącz dla LCD.
-
Jutro przetestuję dwa różne wyświetlacze z innymi wyprowadzeniami.Ten na zdjęciu ma wyprowadzenia w jednym rzędzie od 1 do 16.Ten drugi ma dwa rzędy po7 pin oraz oddzielne 2 piny pod podświetlanie.PCB można już robić,ale poczekajcie do poniedziałku.OC wyprowadziło sygnały na łączówkę 40 pin gdzie sygnały E (4 dla 4LCD) są na różnych pozycjach.Do taśmy 40 żył równolegle zaciskają 4 łączówki żeńskie dla 4 wyświetlaczy.
http://www.opencockpits.com/modules.php?name=Content2&pa=showpage&pid=62
U nas można to rozwiązać podobnie trochę modyfikując.Jak można to rozwiązać to jest sprawa do dyskusji.Jeśli założymy,że zrobimy małą płytkę przy wyświetlaczu patrz moje zdjęcie prototypu z możliwością wyboru pinu dla E to mamy ładniejsze rozwiązanie od OC.Rozwiązań jest dużo,jest to sprawa do dyskusji.
-
damos - miałem na myśli driver prądowy :) Ale jeśli jest oka to super.
Co do złącz, dodatkowe płytki do każdego wyświetlacza to dodatkowe koszty. Można by zastosować takie gniazda i wtyczki jak to zrobił vito_zm w układzie testowym (2x8 jeśli się nie mylę). Można zrobić 3 rzędzy po 7 takich gniazd w każdym, i kwestia potencjometru do kontrastu - albo pominąć na PCB i każdy dorobić na kablu przy LCD albo wrzucić na PCB - wtedy albo używamy potencjometru na PCB albo na kablu. Kwestia gustu.
Jeszcze jedno - jeśli będziemy zamawiać płytki tak jak przy encoderze do MJoy'a to taniej wyjdzie (chyba) jeśli od razu będziemy mieć gotowe płytki do diód LED i wyświetlaczy 7-segmentowych.
Edit:
Co do .NET'a. Jeśli damos udostępnisz jakąś bibliotekę do sterowania wyświetlaczami to jakoś sobie poradzę :001:
-
Damos obliczył,że dodatkowy driver jest niepotrzeby oraz,że wystarczy do zasilania USB.W układach uP daje się układy buforujące uP od peryferiali,jest to do uzgodnienia.Co do szczegółów to jeszcze uzgodnimy.Prawdopodobnie potencjometry będą indywidualne (wyjdzie to po testach u Damosa oraz u mnie).
Jeszcze jedna uwaga.Sterownik jest uniwersalny obliczony na 21 LCD.W praktyce ich liczba będzie zależała od aplikacji i umiejętności ich programowania.
U nas na dzień dzisiejszy są tworzone 2 aplikacje FSX (Codeking) oraz Falcon (Gerrah).
Damos realizuje następne taski w swoim programie,ale czy Codeking oraz Gerrah próbują integrować swoje aplikacje z softem Damosa.Może to jeszcze jest za wcześnie?
Jedno jest pewne,że można w tym tygodniu rozpocząć pcb.
-
Widzę, że prace idą na przód. zaraz zaczną się przymierzać do projektowania PCB. Może zrobić tak ze złączami, że będzie ich 21 złącza typu 2x8 oraz miejsce na potencjometr do każdego o oprócz tego duże złącze / 2x20 / na taśmę do podłączenia wszystkich wyświetlaczy na jednej taśmie i wtedy potencjometry do wlutowania w kabel. Podobnie było z płytką encoderów dwa rodzaje złącz, aby płytka była jak najbardziej uniwersalna Dołożenie tego dodatkowego złącza dużo, nie podniesie kosztów płytki / niewiele więcej miejsca to zajmie, a każdy będzie mógł podłączyć tak jak chce /.
Damos, mam pytanie czy przewidujesz w swoim projekcie sterowanie wyświetlaczami 7-segmentowymi, jeżeli tak to mogę Ci podesłać płytkę wraz z wyświetlaczami jaką kiedyś zrobiłem do FSBUS-a. Mam ich parę sztuk, a projekt jest w drukowane.pl.
(http://img188.imageshack.us/img188/8401/7segment.th.jpg) (http://img188.imageshack.us/i/7segment.jpg/)
pozdrawiam Zając
-
Teoretycznie mogę zacząć już - potrzebuje tylko biblioteki od damosa do obsługi wyświetlacza i później mogę podesłać do sprawdzenia. Urządzenie zrobię gdy będzie już dostępne PCB itd. Ze swojej strony napiszę jeszcze, że aplikacja, którą piszę nie ogranicza się do FSX'a. Wszystko zależy od tego czy ktoś inny poza mną podejmie się implementacji biblioteki do obsługi innej gry. No i zaimplementowałem nowy format skryptów przypominający już prosty język programowania. Do zrobienia są jeszcze różne funkcje wbudowane itd. Jak aplikacja będzie już w takiej fazie, że będzie możliwe wykorzystanie jej (albo przynajmniej sprawdzenie) w "akcji" to udostępnię ją na forum z opisem "co i jak".
-
Codeking jeśli Twój program nie ogranicza się tylko do FSX to skontaktuj się może z Gerrah być może dublujecie jakieś procedury.Jako programiści możecie to łatwo sprawdzić.Może jest możliwość współpracy
pozdrawiam i życzę powodzenia
-
Ja ostatnio programowanie mam na on-hold. Zająłem się dość poważnie inną dziedziną kokpitu, która wymaga dużej ilości sklejki, kleju, potu i krwi ;) Postaram się w tym tygodniu z powrotem wejść w temat programowania.
-
Przy realizacji projektu elektronika oraz implementacja softu (jest to przyjemniejsza część pracy)to może 5% czasu,pozostały czas to "prace ręczne".
Ponieważ projekt jest realizowany w dużym tempie i przy zaangażowaniu kilku osób ta dobrze byłoby gdybyś także wrócił do tematu.Bez Twojej pomocy nie jestem w stanie przetestować LCD w Falconie
pozdrawiam,vito_zm
-
Dwie osoby: "codeking" i "zając" wyraziły zainteresowanie obsługą wyświetlaczy 7-segmentowych oraz diód świecących. W związku z tym porozmawiałem w nocy z zającem o sensowności zrobienia uniwersalnego PCB, które będzie takie samo dla wszystkich modułów i bądzie zawierać ATMega16 wraz z supportem dla USB. Do niej podłączało by się peryferia typu wyświetlacze LCD, LED, diody itd... Co Wy na to? Była by to solidna podstawa do budowania różnych urządzeń. Wszystkie one były by na PC obsługiwane jednym, spójnym interfacem.
-
Wyświetlaczami 7 segmentowymi jestem też zainteresowany ja (i Vito z pewnością). A nawet bardziej, do tego wszystkiego dorzuciłbym jeszcze LCD na KS0108 ;)
Vito: ok, dzisiaj postaram się zająć pozostałymi danymi z pamięci współdzielonej.
-
KS0108 - nie ma problemu :)
Do każdego rodzaju urządzeń zewnętrznych będzie osobna płytka ATMega16USB z tym samym PCB a jedynie oprogramowaniem dedykowanym do:
- LCD HD44780
- LCD KS0108
- LED 7-SEG (+ dodatkowe małe płytki zewnętrzne (np. jedna na 6 LED 7-seg), płytki łączone szeregowo z minimalna ilością kabli )
- LED - pojedyncze lampki (+ dodatkowe małe płytki zewnętrzne (np. jedna na 32 lampki ), płytki łączone szeregowo z minimalna ilością kabli )
Co wy na to ?
-
Dobre i uniwersalne rozwiązanie. Czyżby sen się spełniał i powstawała rodzima platforma bardziej uniwersalna od OC i FBUS?
Trzymam kciuki!
-
Witam,
bardzo dobre rozwiązanie,nawet bardziej oszczędne niż OC.Wymiana kości uP to jest pomysł.Łatwo to uzasadnić.Gdybyśmy zrobili uniwersalną płytę główną tzw.matkę realizującą zakładane peryferiale to trzeba byłoby użyć dużą ilość łączówek i rozbudowany soft.
W naszym rozwiązaniu płyta główna posiada rozsądną liczę wyprowadzeń (łączówek) a peryferiale (płyty córki) plus program w kości decydują o funkcji hardware.Przesyłanie szeregowe dodatkowo redukuje liczbę kabli.
Dodam tylko od siebie,że tak się projektuje duże systemy.OC oraz PHCC także stosuje tzw.dekompozycje czyli płyta matka i córki.W naszym rozwiązaniu jest patent Damosa tzn.wymiana kości uP.
Mamy szansę zaprojektować funkcjonalny system realizujący popularne elementy wykonawcze LED 7-seg., LED oraz LCD.
Co do szczegółów to można zrobić sprawdzone rozwiązanie sterowania 7-seg.LED, tzn.LED z wspólną katodą podpięta do ULN2003,która pełni funkcje enable.7 połączeń wspólnych wprost z uP (może być bufor).
Zwykłe LED można sterować z HC259 szeregowy zapis do 8 komórek pamięci.
Co do szczegółów dotyczących córek to jest jeszcze czas.Można już zaprojektować płytę główną.
Na zakończenie reflekcja.Powstanie uniwersalne rozwiązanie z możliwością komunikowania się z PC przez USB.Będzie to platforma dla programistów piszących aplikacje.I tutaj jest duże pole do popisu dla programistów.Bez aplikacji system jest martwy.
Teraz pora na moje sprawozdanie.Sprawdziłem podłączając 2 różne LCD na różnych adresach.I tutaj niespodzianka,która kosztowała mnie uszkodzenie kilku segmentów w jednym LCD.LCD z wyprowadzeniem w dwóch rzędach po 7 pin ma te same przypisania do numerów pin co układ z jednym rzędem 16 pin z jednym wyjątkiem na pin 1 jest VCC a na 2 GND czyli odwrotnie.Można zamienic na schemacie Damosa na pin 1 dać VCC a na 2 GND.W ten sposób można używać tego samego kabla dla różnych typów LCD.
(http://img269.imageshack.us/img269/2038/dscn2374.th.jpg) (http://img269.imageshack.us/i/dscn2374.jpg/)
(http://img269.imageshack.us/img269/5513/dscn2375v.th.jpg) (http://img269.imageshack.us/i/dscn2375v.jpg/)
(http://img269.imageshack.us/img269/8710/dscn2376.th.jpg) (http://img269.imageshack.us/i/dscn2376.jpg/)
-
Co do szczegółów to można zrobić sprawdzone rozwiązanie sterowania 7-seg.LED, tzn.LED z wspólną katodą podpięta do ULN2003,która pełni funkcje enable.7 połączeń wspólnych wprost z uP (może być bufor).
Proponuje ULN2803 - kropka na wyświetlaczu też się przyda ;) Tego ULN można wykorzystać do zasilania LEDów :)
Programiści czekają na gotowe urządzenia, żeby było co oprogramowywać :)
Na viperpits znalazłem bibliotekę .NET do odczytywania danych z Falcona. Jeśli ktoś reflektuje to dorobię obsługę w aplikacji którą tworzę i podeśle do prostych testów.
-
Ja reflektuję.Czy możesz w prosty sposób wyjaśnić jak się odczytuje dane z Falcona,jakim narzędziem.Na viperpits programiści korzystają z pamięci współdzielonej pisząc programy a ja nie mam pojęcia jak to się robi
ps
nie mam przycisków kodu BBC np.cytuj itp.Co mam ustawić?
-
Postaram się przygotować program do testów (na sucho bez LCD bo nie mam biblioteki do sterowania nim) jak najszybciej, może uda się do jutra.
W znalezionej bibliotece też korzystają z pamięci współdzielonej. Na pewno widziałeś już tą stronę http://www.assembla.com/wiki/show/lightningstools - "
Falcon Shared Memory Reader Library v2.0 for .NET & COM" - temat na forum: http://www.viperpits.org/smf/index.php?topic=3358.msg45800#msg45800
Co do BBCode - nie mam pojęcia.
-
prawie off-top: zaglądając do jednego z linków codekinga zauważyłem, że beta innovations już "nie żyje". Oni mieli masę ciekawych, profesjonalnych rozwiązań. Za mało klientów czy za duże ceny ?
-
Beta innovations padła chyba na początku tego roku.Teraz wszyscy z viperpits przeszli na PHCC
http://www.viperpits.org/smf/index.php?topic=3962.0
i piszą pod to programy.Ja jestem jednym z nielicznych,którzy stosują rozwiązania OC oraz program FAST.Na viperpits niektórzy są wyspecjalizowani w tworzeniu różnych elementów kokpitu zarówno mechanicznych jak i elektrycznych.Chcąc oszczędzić czas większość zamawia gotowe rozwiązania.Dotyczy to także elektroniki.
U nas prawdopodobnie będą powstawały pojedyncze aplikacje pod konkretne potrzeby wykorzystujące możliwości naszego hardware.Nie sądzę,że jesteśmy w stanie stworzyć coś podobnego do SIOC.Ale aplikacje to też dobry sposób na realizację sterowania panelami.
ps
przejrzę podane linki i będę pytał.
-
Czy aplikacje i hardware o których tutaj rozmawiacie mają szanse działania także pod FS2004? Planowałem budowę czegoś w miarę uniwersalnego na bazie mJoy'a + Encoder's + FSLCD ale jeśli to rozwiązanie byłoby lepsze od FSLCD to się jeszcze wstrzymam
Trzymam kciuki za udany projekt
i Szacuneczek za zaangażowanie
-
Noker to będzie coś więcej,aplikacje też powstaną,liczę na naszych kolegów.
-
Hardware i bazowa aplikacja do sterowania nim będą kompletnie niezależne od jakiegokolwiek symulatora. Będziesz mógł używać ich z dowolnego FS'a a nawet zrobić sobie na tym sterowanie oświetleniem w domu przez internet :)
-
a nawet zrobić sobie na tym sterowanie oświetleniem w domu przez internet :)
Damos.. jaja sobie teraz robisz.. 8-)
Jeśli tak, to już zaczynam zmieniać plany (czytaj marzenia) co takiego sobie zainstaluję w domu, jeśli będzie mi dane kiedyś taki wybudować :)
-
Damos.. jaja sobie teraz robisz.. 8-)
Mówię zupełnie serio. Główny kontroler będzie pracować jako serwer sieciowy - wystawiasz go więc na publicznym IP. Zamiast diod podłączasz przekaźniki a do nich odpowiednie oświetlenie lub inne odbiorniki energii elektrycznej. Łączysz się z serwerem przez internet (przez interface WWW albo odpowiedni software) i ... zamiast zapalać lampkę Master Warning zapalasz światło w salonie ;)
-
Witam,moje gratulacje Codeking.Twój program działa poprawnie.Na zdjęciu widać wartości fuel flow w kokpicie oraz w testowym programie podobnie z DED (są takie same),Falcon pracuje w trybie okienkowym.
(http://img195.imageshack.us/img195/5954/testfalcontrybokienkowy.th.jpg) (http://img195.imageshack.us/i/testfalcontrybokienkowy.jpg/)
Czy możesz mi jako laikowi w programowaniu wytłumaczyć w posty sposób jak korzystasz z Share Memory Reader Library v 2.0 for NET&COM?
Czy procedury w tej bibliotece umożliwiaja pobranie danych w RAM tzn.wiadomo pod którymi adresami są zapisane parametry zmiennych symulatora np.dane z DED itp.
Pytanie do Damosa.
Czy masz koncepcję sterowania peryferiali (płyty córki) z płyty głównej (płyta matka).Jest możliwych kilka rozwiązań.
Można to zrobić tak jak OC czyli przesyłać dane po jednej szynie adresując odbiorniki.
Można przesyłać dane także po jednej szynie w jednym kierunku i po drugiej w drugim półduplex synchronicznie z zegarem (RS232 synchroniczny) z protokolem .To wymaga wyspecjalizowanego układu.
Przesył danych po BUS nie rozpatrujemy z wiadomych względów.
Jest też możliwe łączenie dwóch sposobów komunikacji z PC przez płytę główną oraz niezależne moduły przez USB (rozwiązanie OC).
Jakie jest Twoje zdanie.
-
Czy możesz mi jako laikowi w programowaniu wytłumaczyć w posty sposób jak korzystasz z Share Memory Reader Library v 2.0 for NET&COM?
Czy procedury w tej bibliotece umożliwiaja pobranie danych w RAM tzn.wiadomo pod którymi adresami są zapisane parametry zmiennych symulatora np.dane z DED itp.
Szczerze mówiąc to ta biblioteka robi czarną robotę za mnie :) Wieczorem udostępnię kod źródłowy tego programiku. W źródłach biblioteki nie widzę adresów pamięci, podejrzewam (bez głębszej analizy więc mogę się mylić), że czytany jest w niej ciągły blok pamięci z której później wydobywane są dane. Ilość informacji, które można odczytać nie jest specjalnie duża. Ściągnij sobie źródła (link podawałem wcześniej), w pliku FlightData.cs na dole jest lista informacji, które można pobrać z Falcona. Może Gerrah wie skąd odczytać inne ?
-
Wydaje mi się,że nastapił przełom mam na myśli Falcona.Co do FS to nie ma problemu jest to opisane także w OC (mam na myśli soft).Ja byłem uzależniony od OC ze względu na soft OC oraz aplikację mihi czyli FAST.Teraz sytuacja uległa zmianie tzn.możemy próbować pisać aplikacje pod Falcona wykorzystując tworzoną przez nas platformę (hardware).Możemy metodą małych kroków robiąc testy zrealizować sterowanie dla różnych symulatorów pod warunkiem,że jest dostęp do ich danych.
-
Pytanie do Damosa.
Czy masz koncepcję sterowania peryferiali (płyty córki) z płyty głównej (płyta matka).
Moja koncepcja jest taka:
(zrobiłem prosty diagram do prezentacji tej idei)
http://www.damos.k11.pl/LO/diagram/index.htm
Diagram na początku wygląda dziwnie - potrzebuje chwile na załadowanie się - później wypełnia całą przestrzeń okna przeglądarki.
Jest tam ogólnie pokazane, jak informacje z symulatora są pobierane i wysyłane dalej za pomocą TCP do kontrolera (np. LUA może samodzielnie wysyłać dane po sieci). Kontroler może być na tej samej maszynie - to nie problem. Powinien być serwisem windows lub osobną aplikacją. Dla jasności został umiejscowiony na innej.
Punkt styku oparty na TCP zdejmuje konieczność tworzenia bibliotek dla różnych języków i różnych systemów op.
W "Serwerze" każda płyta "matka" (MB) jest podłączona bezpośrednio do USB a do niej są podłączane płyty "Córki" (DB). Płyt-matek jest wiele, ale każda jest taka sama (to samo PCB, kod uP inny). Każda płyta-matka zawiera minimum potrzebne do obsługi USB (procesor, gniazdo USB, kwarc, rezystorki) i złącze do podłączenia peryferiów. Każda jest osobna dla każdego rodzaju peryferiów: LCD HD, LCD KS, LED, 7-SEG... i różni się... programem dla mikrokontrolera. Pozwala to na:
- uproszczenie kodu uP
- szybsze działanie uP
- odseparowanie od siebie potencjalnych miejsc występowania błędów (hardware uP, kod uP)
- równoległe wysyłanie danych do kilku MB, ATMega ma powolne USB, można wykorzystać lepiej potencjał tej magistrali wysyłając różne dane w tym samym czasie do kilku MB i żadna nie musi czekać na synchronizację z inną. Sumarycznie - czas akwizycji danych/komend jest krótszy, ponieważ nie zależy od ilości MB. Namacalnie - diody szybciej się zapalają, LCD szybciej pokazują tekst.
Płyty-córki (DB) z założenia zawierają maksymalnie uproszczony hardware i można je łączyć w stosy (tzn - pierwsza płytka ze stosu podłączona do MB, reszta kaskadowo do siebie). To powinno zmniejszyć ilość okablowania.
-
Damos jestem pod wrażeniem,masz wyobraźnię,ambitna koncepcja.Mam trywialne pytanie czy córki DB łączą się z matką MB tak jak w przypadku naszego LCD za pomocą kilku przewodów z uP (może być bufor) i są wybierane do zapisu linią enable.Czy jest to podobne rozwiązanie do OC.
-
Kontroler może być na tej samej maszynie - to nie problem. Powinien być serwisem windows lub osobną aplikacją. Dla jasności został umiejscowiony na innej.
Czy to oznacza możliwość uruchomienia oprogramowania do sterowania peryferiami i samych peryferiów na maszynie, na której NIE JEST zainstalowany symulator?
-
Damos jestem pod wrażeniem,masz wyobraźnię,ambitna koncepcja.Mam trywialne pytanie czy córki DB łączą się z matką MB tak jak w przypadku naszego LCD za pomocą kilku przewodów z uP (może być bufor) i są wybierane do zapisu linią enable.Czy jest to podobne rozwiązanie do OC.
To jest właśnie mało ambitna, ale prosta koncepcja :)
Płyty-córki 7-seg i LED łączą się z MB za pomocą następującej szyny:
- VCC (ale to VCC nie może zasilać 7-seg, bo USB nie "wydoli" prądowo na 100% :)
- GND
- DATA
- CLK
- LATCH
Więc pomijając zasilanie mamy tam 3 przewody do transmisji szeregowej.
Moja idea układu polega na użyciu tych kości, które ci wysłałem kiedyś w paczce. Każda ma szeregowe wejście, równoległe wyjście i szeregowe wyjście do następnego stopnia. W porównaniu do OC pomijam etap adresowania - wpuszczam szeregowo dane do magistrali równoległej (na schemacie to tzw. "stack" ) o znanej długości i po wypełnieniu przepisuję dane do zatrzasków. Całość korzysta z kości jednego rodzaju, co pozwala na zakup dużej ilości jednego elementu (niższa cena) i dowolną ich wymianę między sobą w przypadku awarii.
Nie jestem pewien co do ilości "stacków" - czy będą to na pewno 24, czy 16 czy mniej bo nie mam przy sobie swoich notatek. Jednak ogólna idea jest bardzo prosta i 24 wydaje sie osiągalne:
ATMega ma 32 porty wyjsciowe:
2 - na USB
1 - CLK (współdzielony przez wszystkie stacki
1 - data (współdzielony przez wszystkie stacki)
4 - do czegoś były potrzebne, ale nie pamiętam, do czego :)
pozostaje 24 na latch'e: do każdego stack'a osobny (albo i 28 - jeśli te 4 nieznane w przypadku USB będą wolne).
Latch powoduje na danym stacku zapamiętanie wysłanych danych (z resztą, komu ja tłumaczę działanie latch'a :) ) Innymi słowy - jest to pewna wariacja dla sygnału "enable". Ale ja wysyłam go do wszystkich płyt-córek w danym stacku.
ot - i cała "magia".
W tym układzie 7-seg nie są multipleksowane (jak w OC), ale też nie trzeba im kosztownego uP ani drivera ani oporników... Dla diod LED też nie trzeba każdej do opornika podłączać - w sumie: mniej kabli i mniej elementów.
Ponadto w przypadku LED 7-seg będzie można wyświetlić dowolną kombinację segmentów - niedostępną za pomocą kodu BCD.
Czy to oznacza możliwość uruchomienia oprogramowania do sterowania peryferiami i samych peryferiów na maszynie, na której NIE JEST zainstalowany symulator?
TAK :118: I będzie to mógł być stary rupieć na darmowym Linuxie.
-
Bardzo ciekawa koncepcja.Czy robiłeś już jakieś testy tego projektu?Jeśli nie to mogę podłączyć wspomniany układ do mojego prototypu z LCD i jakimś programem testującym sprawdzić jak to się zachowuje.Oczywiście nie ma pośpiechu
pozdrawiam
-
Czy robiłeś już jakieś testy tego projektu?
Tak - jakiś rok temu lub dawniej testowałem ten wariant, ale na krótkiej kaskadzie - bodaj 3 lub 4 układach (to i tak dużo diod :) )
mogę podłączyć wspomniany układ do mojego prototypu z LCD i jakimś programem testującym sprawdzić jak to się zachowuje.
Hmm.. postaram się w ciągu 2 dni dostarczyć ci wsad do uP i program testujący
-
TAK :118: I będzie to mógł być stary rupieć na darmowym Linuxie.
Fantastyczna nowina :)
damos - mistrzu ;)
-
damos -to wygląda imponująco :karpik pozostaje czekać i dopingować :)
Ale sam coś też skrobię i postanowiłem pokazać coś niecoś, na razie na sucho bez żadnych urządzeń, bez kontaktu z FS czy Falconem, tak po prostu żeby zobaczyć. Program z plikiem zawierającym dwa przykładowe profile skryptów do zabawy - http://angus.foxnet.pl/fs/DomowyKokpit.zip (http://angus.foxnet.pl/fs/DomowyKokpit.zip) . Do programu dołączony jest też moduł do testowania. Wszystko opisałem w pliku z rozszerzeniem .hcps (to jest zwykły plik tekstowy tylko ma takie dziwne rozszerzenie :) ). Program wystarczy uruchomić (wymaga MS Framework .Net 2.0), wczytać ten plik .hcps, wybrać profil z listy (są tylko 2 więc wielkiego wyboru nie ma :118: ), potem zakładka "Moduły wejścia", zaznaczenie modułu "TestModule", przycisk "Konfiguracja...", przełączamy się spowrotem do głównego okna i klikamy "Uruchom" aby rozpocząć zabawę.
Jest to bardzo wczesna wersja więc może się "przewracać", a jeśli się przewróci lub na zakładce "Log" zaczną wyświetlać się duże ilości dziwnych informacji to proszę o podesłanie ich do mnie na priv.
Edit: przypomniałem sobie, że miałem wrzucić kody źródłowe programiku do sprawdzenia biblioteki odczytującej dane z Falcona -> http://www.angus.foxnet.pl/fs/FalconTest.zip
-
Hmm.. postaram się w ciągu 2 dni dostarczyć ci wsad do uP i program testujący
Wsad do uP już mam. Teraz tylko program testujący....
-
Codeking jeszcze nie sprawdziłem Twojego programu,ponieważ kupiłem nowy PC i mam kilka problemów do rozwiązania,prawdopodobnie skończy się to wizytą w serwisie.
Damos jesteś rewelacyjny.Jak będziesz miał gotowy soft przyślij mailem (podłączenie scalaka do uP także,na które nóżki uP).Postaram się zrobić testy i zobaczyć jak to działa
pozdrawiam,vito
-
@vito_zm:
Soft na PC do testowania sterowania LED gotowy.
Tu jest paczka razem z wsadem do uP: http://www.damos.k11.pl/LO/led_avr/schemat_damos_usb_led.png
Jeśli używasz firefoxa - nie przejmuj się ostrzeżeniem. Google bot wlazł mi na stronę, sparzył się na powitalnym skrypcie odstraszającym ciekawskich i z zemsty wrzucił mi domenę na listę zbanowanych :) Bezczelność.... :karpik
Schemat jest tu:
http://www.damos.k11.pl/LO/led_avr/schemat_damos_usb_led.png
Układ jest "kompatybilny" z kaskadą 2 sztuk MBI5026 (IC2, IC3), nie pamiętam, które kości ci wysłałem, ale chyba te.
1 - ATmega16 (IC1) ma to samo podłączenie do USB, co moduł LCD.
2 - układ pokazuje jeden, najmniejszy "stack" z uprzednio zaprezentowanego diagramu.
co tam jest, otóż:
dla wszystkich "stack'ów" są dwa współdzielone sygnały:
- z pinu 20 uP wychodzi sygnał CLK do wszystkich układów w stosie
- z pinu 19 uP wychodzi sygnał SDI (serial data in) do pierwszego układu w stosie
dla każdego ze stacków jest jeden, indywidualny sygnał:
- "Latch Enable" - należy podłączyć z jednego z pozostałych pinów, numeracja linii sterujących w funkcji pinów uP jest następująca: (uwaga - kolejność "od-do" nie jest przypadkowa !) Wyjście to działa jak "chip select" i nie może być współdzielone.
piny 40-33 linie 0-7
piny 22-29 linie 8-15
piny 1-8 linie 16-23
piny14-15 linie 24 i 25
pin 17 linia 26
pin 21 linia 28
Z IC2 pin 22 mamy kaskadę do IC3 na pin 2.
W obu układach pin 21 (output enable) jest zwarty do masy - aby umożliwić sterowanie diodami.
Pin 23 razem z rezystorem odpowiadają za prąd płynący przez diody LED.
Oba drivery mają własne (inne niż ATmega, która pobiera prąd z magistrali) zasilanie i raczej nie należy pobierać dla nich prądu z USB.
Co zrobić?
Zmontować, uruchomić program, następnie wybrać linię, która steruje chip select'em (analogiczna metoda jak w przypadku LCD) i później klikac sobie na symbolach diod zapalając je lub gasząc.
"U mnie działa" - jakby co ;) :021:
Udanych testów ! A ja idę się przespać przed pracą :118:
-
Tu jest paczka razem z wsadem do uP: http://www.damos.k11.pl/LO/led_avr/schemat_damos_usb_led.png
Damos chłopie, musisz się wyspać :) Podmień link na właściwy :) Świetna robota :)
-
sorry... poprawny link: http://www.damos.k11.pl/LO/led_avr/led_usb.rar :)
To chyba przez niespodziankę od Googla :(
-
Witam,mam nowy pc i jestem trochę zajęty.Jeszcze nie uruchomiłem projektu Damosa,ale to zrobię .Patrząc na schematy zauważyłem,że przy naszej koncepcji możemy realizować małe projekty wymieniając uP w matce MB oraz dobierając odpowiednią córkę DB.
Przy projektach złożonych gdy potrzebujemy wszystkie rodzaje peryferiali to musimy zastosować kilka MB z odpowiednimi DB.Czy możesz Damos to potwierdzić?
Uruchomiłem program Codeking co widać na zdjęciu,ale mam zablokowany dostęp do danych.Może robię coś nie tak?
(http://img30.imageshack.us/img30/5034/testcokdeking.th.jpg) (http://img30.imageshack.us/i/testcokdeking.jpg/)
-
Z listy w polu "Profil" (combobox) trzeba wybrać jeden z profili i kliknąć na "Uruchom" (uaktywni się gdy będzie wybrany jakiś profil).
-
Witam,mam nowy pc i jestem trochę zajęty.Jeszcze nie uruchomiłem projektu Damosa,ale to zrobię .Patrząc na schematy zauważyłem,że przy naszej koncepcji możemy realizować małe projekty wymieniając uP w matce MB oraz dobierając odpowiednią córkę DB.
Przy projektach złożonych gdy potrzebujemy wszystkie rodzaje peryferiali to musimy zastosować kilka MB z odpowiednimi DB.Czy możesz Damos to potwierdzić?
Dokładnie tak (z tym, ze nie trzeba wymieniać uP - wystarczy go przeprogramować). Już o tym pisałem - taka idea jest też pokazana na diagramie. To rozwiązanie ma kilka zalet, o których też już pisałem :)
-
Hmm, to może by pomyśleć o płytce PCB zawierającej tylko ATmegę i elementy dyskretne oraz 'zasilacz' i ewentualnie złącze do programowania. To byłaby taka uniwersalna matka, a do niej można by dopinać córki. Takie rozwiązanie byłoby bezpieczniejsze niż 'przekładanie' scalaka.
-
Zdecydowania tak + duże złącze do córek / może kątowe, żeby je od razu łączyć i musiały by mieć tę samą szerokość, ale to nie problem / już się do tego przymierzam.
pozdrawiam Zając
-
Hmm, to może by pomyśleć o płytce PCB zawierającej tylko ATmegę i elementy dyskretne oraz 'zasilacz' i ewentualnie złącze do programowania. To byłaby taka uniwersalna matka, a do niej można by dopinać córki.
:118: Dokładnie tak to zostało zaprojektowane:
Moja koncepcja jest taka:
(zrobiłem prosty diagram do prezentacji tej idei)
http://www.damos.k11.pl/LO/diagram/index.htm
[...] każda płyta "matka" (MB) jest podłączona bezpośrednio do USB a do niej są podłączane płyty "Córki" (DB).
Płyt-matek jest wiele, ale każda jest taka sama (to samo PCB, kod uP inny).
Każda płyta-matka zawiera minimum potrzebne do obsługi USB (procesor, gniazdo USB, kwarc, rezystorki) i złącze do podłączenia peryferiów.
Już to sobie z Zającem omawialiśmy :)
edit:
@vito_zm - w nocnym amoku ( :) )zapomniałem dopisać, że diody podłączasz do wszystkich "odnóży" w IC2 i IC3 (od 5 do 20). Pokazane na schemacie to jedynie przykład mający pokazać polaryzacje diod. Każdy driver (IC2, IC3) obsługuje 16 diod świecących.
-
Już o tym pisałem - taka idea jest też pokazana na diagramie. To rozwiązanie ma kilka zalet, o których też już pisałem
Jak zwykle masz rację.Problemy z nowym PC trochę mnie przytępiają.Przy okazji chciałem sprawdzić diagram i nie można go otworzyć.
Oczywiście programować można na MB nie wymaga to aż tak dużo elementów.
Sprawdziłem jak rozprowadzają zasilanie w OC.Głównym źródłem zasilania jest zasilacz zewnętrzny podłączony do MB (nazywanej Master).Z MB pobierają zasilanie DB (córki).W wersji z LPT masy PC oraz zasilacza są połączone.
W wersji z pakietem USB Expansion zasilacz zewnętrzny jest połączony równolegle do zasilania USB,na pin 1(USB) +5v na pin 4(USB) GND.Pakiet ten łączy się z 4 pakietami MB (Master) przez DB25.
Reasumując źródło zasilania zewnętrznego jest dostarczone do płyt MB (Master może ich być 4).Płyty te są źródłem dla DB.
Z jakiegoś powodu USB Expansion ma także możliwość podłączenia zasilacza.
Codeking już coś się dzieje w Twoim programie,muszę tylko to przeanalizować.
-
Przy okazji chciałem sprawdzić diagram i nie można go otworzyć.
A co dokładnie się dzieje i jaki URL ? Ja go z powodzeniem otwieram na kompie w firmie: http://www.damos.k11.pl/LO/diagram/index.htm . Może ustawienia bezpieczeństwa blokują ci aktywna zawartość strony ? Tam jest JavaScript.
-
Mam odmowę dostępu co widać na załączonym obrazku.
(http://img23.imageshack.us/img23/2095/dladamosau.th.jpg) (http://img23.imageshack.us/i/dladamosau.jpg/)
-
To musi być sprawa konfiguracji twojego kompa. Może Norton blokuje widząc JavaScript? Na serwerze nie ma nic, co by blokowało komukolwiek dostęp do tego materiału. Jak odpalam w firmie z IE - to McAfee właśnie traktuje JavaScript jako treść niebezpieczną i połowicznie blokuje dostęp. Wydaje mi się jednak, że to błędne działanie antywira - w końcu całość strony była wygenerowana z Enterprise Architekta ...
Najszybsze rozwiązanie po wygenerowanie tego jako zwykłego obrazka: http://www.damos.k11.pl/LO/diagram/diagram_jako_image.png
To MUSI się otworzyć ;)
-
Mam diagram.Damos czy dobrze rozumuję.Stack to 2 scalaki (16 wyjść).Wszystkie stacki mają wspólny zegar,wyjścia są połączone z wejściami tworząc bardzo długi rejest szeregowy.Możesz mieć np.24 wyjść strobów LE.Cały rejestr musi być zapisany,ale odczytujesz tylko ten do którego wyślesz strob LE.
Jest to ciekawe rozwiązanie z paru względów.Dla mnie najważniejsze to oszczędność kabli oraz elementów.Moje gratulacje.
-
Mam diagram.Damos czy dobrze rozumuję.Stack to 2 scalaki (16 wyjść)
Prawie, ale nie do końca :) Stack to szereg takich scalaków, od 1 do 30 (w pierwszej wersji jeden stack może zawierać 480-cio bitowy rejestr, jest to uproszczenie wynikające z maksymalnej wielkości bufora przy transferach kontrolnych USB - 64 bajty. Można to później zmienic, ale nie jestem pewien, czy będzie taka potrzeba ). Każdy scalak ma 16 wyjść, więc 2 scalaki to już 32 wyjścia :)
.Wszystkie stacki mają wspólny zegar
tak. Zarówno zegar jak i wejście są wspólne.
wyjścia są połączone z wejściami tworząc bardzo długi rejest szeregowy.
Dokładnie tak. Kolejne "scalaki" są podłączane do siebie w zakresie jednego stacka.
Możesz mieć np.24 wyjść strobów LE. Cały rejestr musi być zapisany,ale odczytujesz tylko ten do którego wyślesz strob LE.
Tak właśnie to działa :) (zmienił bym tylko zwrot "odczytujesz tylko ten" na "zapamiętujesz stan rejestru w tym", bo faktycznie to te rejestry sa Read-Only ;) ) Wyjść strobów mam 28... ;)
-
Przejrzałem jeszcze raz koncepcję sterowania DB dla wersji LED i mam do Ciebie Damos pytanie.W tej koncepcji jest 28 linii odczytujących 2 rejestry wyjściowe,czyli mamy max.56 bajtów do dyspozycji.Czyli jest to rejest szeregowo-równoległy o długości 448 bitów podzielony na pamięci 16 bitowe.Zapis następuje do 2 rejestrów wyjściowych określoną linią LE strobu w odpowiednim momencie czasowym.
Jeśli chcemy zapisać ostatnie 2 bajty to musimy przesłać cały ciąg danych czyli 448 bitów.Jeśli chcemy zapisać pierwsze 2 bajty to możemy przesłać krótki ciąg danych czyli 2 bajty
Jeśli mamy zapas czasu na zapis oraz procedura zapisu wszystkich 448 bitów nie jest skąplikowana to można jedną linią LE zapisać wszystkie rejestry jednocześnie.W tym przypadku odświeżamy z RAM uP stare wartości w rejestrach wyjściowych i zapisujemy nowe.Wadą tej koncepcji jest to,że musimy czekać z odczytem tak długo,aż zostanie wysłany cały ciąg 448 bitów.Czy jest to realne z punktu widzenia programisty,czy może popełniam jakiś błąd?
-
Przejrzałem jeszcze raz koncepcję sterowania DB dla wersji LED i mam do Ciebie Damos pytanie.W tej koncepcji jest 28 linii odczytujących 2 rejestry wyjściowe,czyli mamy max.56 bajtów do dyspozycji.
Nie do końca.
Mamy 28 osobnych rejestrów z wejściem szeregowym i wyjściem równoległym. Taki jeden rejestr to właśnie "stack", ponieważ składa się ze stosu połączonych mniejszych układów.
Każdy "stack" ma maksymalną pojemność 60 bajtów, czyli 480 bitów. Nie ma minimalnej długości. 28 takich stacków daje nam w sumie 13 440 bitów (można wysterować tyle diod LED lub 1680 wyświetlaczy 7-seg lub 280 zestawów każdy po 6 wyświetlaczy 7-seg :karpik - i to za pomocą jednej ATmegi16...)
Zapis odbywa się za pomocą 3 linii:
- pierwsza to CLK - czyli zegar
- druga to SDI - czyli Serial Data In
- trzecia to LE - czyli Latch Enable
Mamy więc 28 linii (odbiorników) odczytujących JEDEN sygnał wejściowy (wspólny dla nich) - linię SDI bit po bicie, zgodnie z sygnałem zegarowym generowanym przez uP (CLK).
Czyli jest to rejest szeregowo-równoległy o długości 448 bitów podzielony na pamięci 16 bitowe.
Nie do końca. Jest to 28 osobnych rejestrów . Każdy o zmiennej długości (maksymalnie 480 bitów). Każdy z osobnym wyjściem równoległym.
Zapis następuje do 2 rejestrów wyjściowych określoną linią LE strobu w odpowiednim momencie czasowym.
Podawanie danych następuje do wszystkich rejestrów w tym samym czasie. Zapis - tylko jednego rejestru, za pomocą wybranej linii LE.
Jeśli chcemy zapisać ostatnie 2 bajty to musimy przesłać cały ciąg danych czyli 448 bitów.
Długość ciągu danych zależy od zdefiniowanej długości rejestru. Ogólnie - zawsze podaję tyle bitów, ile ma dany rejestr.
Jeśli chcemy zapisać pierwsze 2 bajty to możemy przesłać krótki ciąg danych czyli 2 bajty
Jest to ryzykowne. Przy zapisie za pomocą LE zmieniane są wszystkie bity w rejestrze. Tak więc powinniśmy zawsze podać tyle bitów, jak długi jest rejestr. W przypadku rejestru 480 bitowego - trzeba podać tyle bitów. Jeśli podłączyliśmy odbiorniki tylko do pierwszych 2 bitów - możemy podać tylko 2 bity i wywołać zapis. Pozostałe bity poprostu nie będą widoczne na żadnym odbiorniku i można je ignorować. Należy jednak pamiętać, że każdy rejestr może mieć inną długość.
Jeśli mamy zapas czasu na zapis oraz procedura zapisu wszystkich 448 bitów nie jest skomplikowana to można jedną linią LE zapisać wszystkie rejestry jednocześnie.
Nie. Każda linia LE jest osobna dla wszystkich rejestrów. W każdym rejestrze wywołujemy zapis osobno.
Wadą tej koncepcji jest to,że musimy czekać z odczytem zapisem tak długo,aż zostanie wysłany cały ciąg 448 1-480 bitów.Czy jest to realne z punktu widzenia programisty,czy może popełniam jakiś błąd?
Jest właśnie tak. Podajemy wszystkie bity (etap "write" ) a następnie a następnie zatrzaskujemy w rejestrze (etap "store"). Czasowo na uP wygląda to tak:
zapis rejestru 72 bitowego: 100.82 us (dla 1 linii to 9918 fps, dla wszystkich 28 to 354 fps)
zapis rejestru 480 bitowego: 339.7 us (dla 1 linii to 2943 fps, dla wszystkich 28 to 105 fps)
Tak więc szybkość samego uP wystarczy. Problemem będzie przepustowość USB dla HID low speed, USB ControlMessage oraz software'owej implementacji USB ma uP.
Maksymalna teoretyczna prędkość USB ctrlMessage dla low speed to 64 Kbps :) To daje mniej niż 4 fps przy 13 tys. diod :) Faktyczna szybkośc tej implementacji USB na ATmega16 jest mniejsza - jeszcze jej nie mierzyłem dokładnie. MJoy ma USB o prędkości poniżej 10Kbps...
Rozwiązaniem problemów szybkości jest sprzętowe USB. Pracuję nad tym w wolnych chwilach. Jeśli powstanie to będzie w 100% kompatybilne z softem na PC, który zrobię dla obecnego systemu. Jedynie wepniesz inny hardware do USB (zastępując kilka obecnych MB jedną MB mkII) i nie będziesz musiał NIC więcej zmieniać. Mimo zmiany/dodania hardware'u moduł widoczny na diagramie (http://www.damos.k11.pl/LO/diagram/diagram_jako_image.png) jako "ControllerService" zachowa dokładnie ten sam interface i aplikacje zewnętrzne nawet nie będą o tym wiedzieć.
Przypominam, że polecenia zapalenia/zgaszenia konkretnych diod wysyłasz do kontrolera a już on zajmuje się optymalną strategią update'owania tego na USB.
jeśli coś nadal nie jest jasne - proszę o pytania :)
-
Po tym wyjaśnieniu widzę dopiero możliwości tego projektu.Mój błąd polegał na tym,że przez stack rozumiałem te 2 rejestry na schemacie a całość jako 28 x2 czyli 56 bajtów.Teraz widzę,że moje pytania nie miały sensu,ponieważ projekt ma takie możliwości,że trudno sobie wyobrazić jego praktyczne zastosowanie.Właściwie to system jako całość z softem jest dobrym materiałem na patent (kiedyś to było modne,nie wiem jak to teraz wygląda).Jestem pełen podziwu dla Twojej wyobraźni.
Jeszcze raz gratuluję,przepraszam za pytania,ale to mój stary nawyk,gdy coś mam zrobić staram się zrozumieć działanie układu
pozdrawiam,vito_zm
-
projekt ma takie możliwości,że trudno sobie wyobrazić jego praktyczne zastosowanie.
No... dziękuję bardzo - wydaje mi się jednak, że ja bym tam kilka zastosowań znalazł ;) Zgaduje, że chodziło ci o trudność z praktycznym wyczerpaniem możliwości a nie z zastosowaniem ?
Właściwie to system jako całość z softem jest dobrym materiałem na patent (kiedyś to było modne,nie wiem jak to teraz wygląda)
ja to chcę jako opensource wydać a nie patentować :)
przepraszam za pytania,ale to mój stary nawyk,gdy coś mam zrobić staram się zrozumieć działanie układu
I bardzo dobrze! Wszystkie pytamnia mile widziane. W dodatku często odpowiadając na cudze pytania zaczynasz widzieć "dziury" w swoim rozwiązaniu. Rozumiem, że od strony sprzętowej "przyklepujesz" projekt ? Pozostaje mi jeszcze pomiar prądu pobieranego przez drivery i ustalenie, jaki stopień wyjściowy z uP jest potrzebny (bo np. 28x30 dla linii "CLK" daje max 47uA na driver ! :) ).
BTW - z Codekingiem chciałbym porozmawiać o definiowaniu wirtualnych obszarów na wyświetlaczu - on już ma pierwsze przemyślenia za sobą. mam swoja wizję, ale po co ryzykować powtarzanie błędów, przez które ktoś już przeszedł?
-
Zgaduje, że chodziło ci o trudność z praktycznym wyczerpaniem możliwości a nie z zastosowaniem ?
Dokładnie o to mi chodziło.
Co do obciążalności prądowej uP przez wejścia MBI 5026 to można pomyśleć ewentualnie o bramce separującej CLK w każdej DB (bramki są tanie,może być układ tranzystorowy).
-
a ja nieśmiało od siebie zapytam, na jakiej zasadzie będzie działał soft do tego niezwykłego ustrojstwa :) :020:
-
Co do obciążalności prądowej uP przez wejścia MBI 5026 to można pomyśleć ewentualnie o bramce separującej CLK w każdej
Świetny pomysł. Można by to montować tylko w pierwszej DB (reszta w stacku będzie sterowana z niej). Buforować trzeba będzie dwie linie: CLK oraz LE. Jest jakiś mały i tani układ zawierający dwie bramki z otwartym kolektorem ?
a ja nieśmiało od siebie zapytam, na jakiej zasadzie będzie działał soft do tego niezwykłego ustrojstwa :) :020:
A o co dokładnie pytasz? Ogólne wyjaśnienia są na poprzednich stronach. Chodzi o szczegóły czy przybliżenie idei? W planie są dwie wersje softu do sterowania. Właściwie to dwa algorytmy sterowania przełączane w konfigu Jeden dla najszybszej reakcji (kiedy będzie odpalony na osobnym kompie). Drugi dla jak najmniejszego zużycia CPU (żeby nie zabierać CPU symulatorowi - ale wtedy update będzie tylko kilka razy na sekundę).
-
Przejrzałem posty jeszcze raz, bo Damos już raz mi udowodnił, że mam problemy ze wzrokiem, ale nie znalazłem nic, co by mi rozjaśniło wątpliwości. Otóż wyjaśnij proszę, czy będzie to jakaś duża aplikacja sterująca całością projektu, czyli MB i wszystkimi DB równocześnie? Trzeba też rozważyć optymalizację kodu pod względem obciążalności procesora PC? Sam symulator jest dość obciążającym procesem, a reszta? Masz jakiś pomysł?
-
Przejrzałem posty jeszcze raz, bo Damos już raz mi udowodnił, że mam problemy ze wzrokiem
Tam od razu "udowodnił" i "problemy" :)
Trzeba też rozważyć optymalizację kodu pod względem obciążalności procesora PC? Sam
symulator jest dość obciążającym procesem, a reszta? Masz jakiś pomysł?
hmm na razie mam to:
W planie są dwie wersje softu do sterowania. [...] dla najszybszej reakcji (kiedy będzie odpalony na osobnym kompie). Drugi dla jak najmniejszego zużycia CPU (żeby nie zabierać CPU symulatorowi
:)
ale nie znalazłem nic, co by mi rozjaśniło wątpliwości. Otóż wyjaśnij proszę, czy będzie to jakaś duża aplikacja sterująca całością projektu, czyli MB i wszystkimi DB równocześnie?
Autorowi zawsze wydaje się, że wszystko jest jasne, nawet kiedy nie jest :)
Już śpieszę z wyjaśnieniami:
Zgodnie z założeniami:
[...]uniwersalne[...] PCB, które będzie takie samo dla wszystkich modułów i będzie zawierać ATMega16 wraz z supportem dla USB. Do niej podłączało by się peryferia typu wyświetlacze LCD, LED, diody itd... [...] Była by to solidna podstawa do budowania różnych urządzeń. Wszystkie one były by na PC obsługiwane jednym, spójnym interfacem.
Hardware i bazowa aplikacja do sterowania nim będą kompletnie niezależne od jakiegokolwiek symulatora. Będziesz mógł używać ich z dowolnego FS'a a nawet zrobić sobie na tym sterowanie oświetleniem w domu przez internet :)
Mówię zupełnie serio. Główny kontroler będzie pracować jako serwer sieciowy - wystawiasz go więc na publicznym IP. [...] Łączysz się z serwerem przez [...]net
Moja koncepcja jest taka:
(zrobiłem prosty diagram do prezentacji tej idei)
http://www.damos.k11.pl/LO/diagram/index.htm
Jest tam ogólnie pokazane, jak informacje z symulatora są pobierane i wysyłane dalej za pomocą TCP do kontrolera [...]. Kontroler może być na tej samej maszynie - to nie problem. Powinien być serwisem windows lub osobną aplikacją. Dla jasności został umiejscowiony na innej.
Punkt styku oparty na TCP zdejmuje konieczność tworzenia bibliotek dla różnych języków i różnych systemów op.
- Program sterujący (Controller) jest jeden i steruje wszystkimi MB. Do MB podłączone są DB, ale nimi Controller się nie przejmuje (w konfigu jedynie może miec zdefiniowane pewne parametry adresacji).
- Tak, jak jest pokazane na diagramie: MB podłączone do USB na PC, USB kontrolowane przez libusb, a z libusb korzysta jedna aplikacja: Controller.
- Controller będzie serwerem TCP i to będzie jedyna droga komunikacji z nim. Będzie mógł pracować jako Windows Service lub Linux Daemon.
- Protokół komunikacji będzie maksymalnie uproszczony i będzie obejmować:
* konfigurację (definiowanie fizycznych urządzeń takich jak wielkości konkretnych wyświetlaczy i ilości podłączonych diod)
* definiowanie virtualnych urządzeń (takich jak obszary tekstowe na różnych wyświetlaczach LCD, składanie kilku wyświetlaczy 7-seg w jeden, wieloznakowy. Wtedy wysyłasz dane do tego "virtualnego" urządzenia nie martwiąc się, gdzie powinien pojawić się jaki znak lub cyfra)
* wysyłanie poleceń do "virtualnych" urządzeń (np. clear)
* wysyłanie danych do "virtualnych" urządzeń (np. wysyłasz liczbę do virtualnego urządzenia "frequency disp 1" a jeden z wątków Controllera, odpowiedzialny za obsługę danego typu MB już sobie znajdzie, na jakie segmenty ma to trafić i zamieni ją na odpowiednią prezentację binarną właściwą dla tych wyświetlaczy, i wyśle je gdzie trzeba)
W późniejszej wersji Controller zajmie się również:
- symulowaniem mrugania lampek itd.
- przyjmowaniem prośby o wysyłanie zdarzeń danego typu (jak np. kliknięcia klawisza, obrót/zmiana położenia przełącznika, obrót enkodera itd)
- wysyłaniem zdarzeń (eventów) zarejestrowanym klientom (jak np. kliknięcia klawisza, obrót/zmiana położenia przełącznika, obrót enkodera itd)
- generowaniem zdefiniowanych key-kodów (emulacja klawiatury) w odpowiedzi na zdarzenia w urządzeniu USB.
Proces wysyłania danych do urządzeń USB będzie zależny od konfiguracji - albo natychmiast, albo nie częściej niż np. co 30 ms (jest szansa na zakumulowanie większej ilości zmian i wysłanie ich razem i zaoszczędzenie CPU)
Przyznaję, że nie robiłem testów obciążenia kompa przy masowej transmisji USB. Wydaje mi się jednak, że ze względu na "powolność" ATmegi nie powinno to stanowić problemu.
-
no, teraz wszystko jasne :) Może skopiuj poprzedni post celem zamieszczenia go w manualu :)
Pozdrawiam
mickey81
-
Witam,
jestem po testach,układ działa prawidłowo (jak zwykle).Jest jeden MBI 5026,ale dla sprawdzenie projektu wystarczy.
(http://img189.imageshack.us/img189/6776/lcddamostest.th.jpg) (http://img189.imageshack.us/i/lcddamostest.jpg/)
(http://img189.imageshack.us/img189/4615/prototypled.th.jpg) (http://img189.imageshack.us/i/prototypled.jpg/)
Teraz parę spostrzeżeń na temat konfiguracji przyszłego softu.Z tego co pamiętam (konfigurowałem tylko jeden raz)z mojej konfiguracji SIOC to trzeba było wpisać liczbę płyt master oraz córki,rodzaj interfejsu USB czy LPT i jeszcze parę innych rzeczy.W momencie pisania skryptu w SIOC deklarowało się adresowanie konkretnych wyjść oraz wejść.
W naszym przypadku może być podłączonych duża liczba różnorodnych urządzeń.
Zastanawiam się nad jedną sprawą.Informacja jest przesyłana w jednym kierunku u nas oraz w OC,nie ma potwierdzeń w sensie identyfikacji oraz prawidłowego odbioru (np.suma kontrolna)tak może być.Ponieważ nie ma systemu identyfikacji ilości oraz typu DB to ktoś nieuważny może zadeklarować np.10 DB a podłączyć 1 DB i program będzie wysyłał informację do 10 DB,ale to sprawa tego kto to stosuje.
Jeszcze jedno trywialne pytanie do Damosa,może już o to pytałem.Większość urządzeń stosuje USB (mysz,kontroler gier,aparat cyfrowy itp.)Czy są to wyspecjalizowane układy do obsługi USB?Jeśli tak to czy nie można tego typu peryferial zastosować u nas?Może obsługa tego układu przez uP jest nieefektywna.
-
Jeszcze jedno trywialne pytanie do Damosa,może już o to pytałem.Większość urządzeń stosuje USB (mysz,kontroler gier,aparat cyfrowy itp.)Czy są to wyspecjalizowane układy do obsługi USB?Jeśli tak to czy nie można tego typu peryferial zastosować u nas?Może obsługa tego układu przez uP jest nieefektywna.
Nie ma sensu stosowane dodatkowego układu pośredniczącego dla USB. Nadal pozostaje kwestia komunikacji między nim a ATmegą (szybkość). Dodatkowo przychodzi koszt tego układu, lutowanie go, miejsce na płytce. Obecne, software'owe rozwiązanie jest w miarę wystarczające. Później zastosuje się uP Atmela z wbudowaną obsługą USB Hi-Speed - tam dane trafiają po wewnętrznych szynach, co jest dużo szybsze. Na priv już ci dawałem fotkę takiego uP: http://www.damos.k11.pl/elektronika/atmele/IMG_3112.jpg
Producenci myszy nie muszą mieć wysokich transferów. Producenci aparatów cyfrowych w produkcji masowej dodają sobie specjalizowany chip VLSI za kilkanaście $. Mogą nawet korzystać z uP z wbudowaną obsługą USB i potężną mocą obliczeniową - przy cenie cyfrówki to prawie nic.
-
Pamięć zawodzi,rzeczywiście już o to pytałem i otrzymałem odpowiedź,przepraszam.
-
BTW - z Codekingiem chciałbym porozmawiać o definiowaniu wirtualnych obszarów na wyświetlaczu - on już ma pierwsze przemyślenia za sobą. mam swoja wizję, ale po co ryzykować powtarzanie błędów, przez które ktoś już przeszedł?
U mnie obsługa obszarów wyświetlacza jest obsługiwana po stronie Windows'a. Jest zrobiona prosto ale daje fajne możliwości. Pierwsze to definiujesz zbiór pozycji znaków, które należą do obszaru (wiersz i kolumna wyświetlacza). Każdemu znakowi dodatkowo nadajesz numer porządkowy, więc łatwo zrobić aby napis był wyświetlany kolumnami (tzn. znak pierwszy w kolumnie 0 i wierszu 0, znak drugi w kolumnie 0 i wierszu 1 itd.). Dodatkowo obszary mają opcje formatowania. Możliwość wyboru z której strony tekst ma być przycięty jeśli jest dłuższy niż obszar. Możliwość zdefiniowania czy za krótki tekst ma być uzupełniany jakimś innym znakiem i z której strony. I ostatnia opcja (tylko gdy nie ma włączonego uzupełniania) to wyrównywanie tekstu do lewej, centrowanie lub do prawej. To wszystko jest proste w implementacji (ale nie po stronie uP). Niby proste ale daje duże możliwości. Dodatkowo nie wykluczam obszarów kolidujących tzn. zawierających znak (pozycję) już używaną w innym obszarze.
Jeszcze pytanie do Damosa - udostępnisz bibliotekę do bezpośredniego sterowania tymi urządzeniami ew. Tzn. protokół wykorzystywany przy komunikacji PC -> MB (USB) ?
-
Witam,ponieważ nie mam jeszcze możliwości rysowania schematów ideowych to postaram się objaśnić słownie.Moim zdaniem można już robić pcb dla MB.Wprowadzę skróty,które już stosujemy:MB-płyta matka,DB-płyty córki,ST-stack czyli połączone szeregowo z sobą córki.
DB-LED córki realizujące sterowanie 16 LED
DB-LCD córki realizujące sterowanie LCD
BD-7seg córki realizujące sterowanie 7-seg LED
Z założeń wynika,że maksymalny ST dla DB -LED to 30,ST dla DB-LCD to 21.
Na podstawie 2 schematów Damosa można już zaprojektować MB.
Zasilanie alternatywne tzn.z możliwością przełączania.Jeśli mała liczba DB to zasilamy z USB jeśli duża to płyta MB z USB pozostałe DB z zewnętrznego zasilacza najlepiej z PC (masy USB oraz zasilacza połączone).
ST dla DB-LED.
Dla każdego ST złożonego z DB-LED z MB trzeba wyprowadzić 3 sygnały CLK,SDI oraz LE (1-28).Czyli jeśli chcemy zrealizować wszystkie 28 ST to mamy 28 3 pin wyprowadzeń,gdzie CLK oraz SDI jest wspólne dla 28 ST.
DB-LED ma na wejściu łączówkę 3 pin (CLK,SDI oraz linię LE1 -28).Dwa pierwsze sygnały są buforowane inwerterami (dwa w szereg) HC04.
DB-LED ma 2 układy MBI 5026 oraz 16 wyjść do sterowania LED oraz wyjście 3 pin dla następnej córki.
ST dla DB-LCD.
Mamy tutaj 11 wspólnych sygnałów:D0-D7,RS oraz VCC i GND.Potencjometr do regulacji jasności świecenia na DB-LCD.Można na DB zrealizować podświetlanie.Realizacja pcb dla DB-LED nie powinna być problemem.Jeśli zdecydujemy się wyświetlacze z wyprowadzeniami w jednym rzędzie to można realizować wyprowadzenia wg.schematu Damosa,jeśli LCD 2 rzędy po 7pin to na pin 2 jest gnd na pin 1 VCC.
Wymienione powyżej sygnały mogą być wyprowadzone na taśmę do której można wpiąć łączówki.
Jedyny problem to doprowadzenie do DB-LCD sygnału E pin 6.Trzeba doprowadzić indywidualnie do każdej DB-LED jeden przewód z sygnałem E.
Jeśli coś pominąłem to proszę uzupełnić.
ps
Jeśli miałbym dokument np.schemat ideowy to gdzie go umieścić tak aby można go było pobrać klikając link (tak jak to zrobił Damos).
-
Wrzuć ten schemat może jako obrazek na ImageShack. Każdy będzie mógł go pobrać.
Zastanawiałem się, jak podpiąć więcej przełączników typu toggle i wymyśliłem coś takiego
(http://img87.imageshack.us/img87/866/toggleswitchv10.th.jpg) (http://img87.imageshack.us/i/toggleswitchv10.jpg/)
Dioda służy do sygnalizacji zadziałania układu. Między wejście i wyjście klucza 4066 wpina się zaciski pushbuttonów w mjoyu. Druga para 'styków' w kluczu służy do rozładowania pojemności kondensatora. Można to zrobić również za pomocą dwusekcyjnego przełącznika, wtedy rozładowanie pojemności następowałoby poprzez zwarcie jej drugą parą styków przełącznika. Wówczas można zaoszczędzić jeden tor w 4066
-
Witam Panowie
Kolega Arek dał mi link to tego forum jakiś czas temu ale dopiero teraz tu zaglądnąłem.
Też robię projekt I/O (dla swojego kokpitu A320, który buduję od roku) i jak do tej pory jestem troszeczkę dalej niż to co tutaj widzę. Mam dopracowaną komunikację pomiędzy kompem i mikrokontrolerem przez USB. Aplikacja, która to wszystko kontroluje napisana jest w Visual C#. Cały zamysł jest dość podobny, lecz dla moich potrzeb projekt podzielony jest na dwie części, stanowiące 2 oddzielne płytki. Jedna płytka dla GLARE i PEDESTAL a druga dla OVERHEADA. Docelowo jednak wszystko będzie działało na zasadzie: płytka główna + płytki dodatkowe (podobnie jak w Waszym projekcie).
Parametry a raczej możliwości:
• wejścia A/D - 8
• wejścia - 512 (do których można podłączyć włączniki, przełączniki, enkodery) z możliwością rozszerzenia do 1024
• wyjścia LED - 512 z możliwością rozszerzenia do 1024
• 7 segmentowe wyświetlacze - 256
Obecnie nie robiłem nic z wyświetlaczami LCD bo mój kokpit takich nie potrzebuje ale bez problemów będę w stanie sterować takimi wyświetlaczami, więc w przyszłości możliwość taka będzie.
Kilka szczegółów technicznych na koniec:
1. Konfiguracja w 99% odbywa się z poziomu aplikacji PC, więc przyszłościowo odpada przeprogramowywanie MC.
2. Aplikacja PC używa tylko kilku komend do zapisu i odczytu MC więc jest bardzo łatwo adaptować środowisko do dowolnych potrzeb, chociaż nie planuję innych zastosowań niż symulowanie lotu.
3. Aplikacja jest robiona pod FSX więc ze światem komunikuje się poprzez Simconnect co daje możliwość uruchomienia jej na dowolnym, kompie w sieci.
Na koniec coś co pewno się wam nie spodoba - mój projekt jest zrobiony na PIC18f4550 :015:
-
Witamy na naszym forum.Mam z Arkiem kontakt ale na priv.Zachęcam go do zaprezentowania swoich osiągnięć na naszym forum.Mam nadzieję,że zaprezentuje ostatnie swoje dzieło HUD dla Falcona.
Nasz pomysł zrodził się przypadkowo.Są konkretne potrzeby głównie dla FS oraz Falcona i kolega Damos zaproponował rozwiązanie dla naszych doraźnych potrzeb.W trakcie dyskusji doszliśmy do wniosku,że można zrobić coś więcej i powstaje uniwersalna platforma dla sterowanie układów wykonawczych.Układy wejściowe typu analog,przełączniki,enkodery realizujemy odzielnie z pomocą MJoya.
mój projekt jest zrobiony na PIC18f4550
Ponieważ jest nas mało i każdy reprezentuje swoje umiejętności dlatego ten a nie inny uP.W naszym zespole Damos ma największą wiedzę oraz doświadczenie zarówno w uP jak i w programowaniu.
Cieszę się,że przedstawiłeś swój projekt.Może będzie możliwość współpracy.Jeszcze raz serdecznie witam na naszym forum i myślę,że kolega Damos będzie miał kilka pytań
pozdrawiam,vito_zm
-
Witajcie,
zajrzałem do Twojej strony Skalarki,robi wrażenie http://www.a320-project.skalarki.co.uk/
W porównaniu z Tobą to dopiero raczkujemy.W związku z projektem mam do Ciebie kilka pytań.
1.Czy projekt jest open tzn.dla wszystkich zainteresowanych.
2.Jeśli tak to czy możesz udostępnić schematy.Chciałbym porównać Twoje rozwiązanie z innymi projektami.
Wracając do projektu to Twój ma większe możliwości niż rozwiązanie OpenCockpits,mam na myśli liczbę wejść oraz wyjść.Chociaż projekt OC można powielać zwiększając jego możliwości.Wadą OC jest cena pakietów.Ja na dzień dzisiejszy jestem skazany na OC z prostego powodu - softu.SIOC komunikuje się z Falconem porzez moduł FAST.FAST jest dziełem falconowca mihi.
FS komunikuje się z SIOC za pośrednictwem FSUIPS.W tym przypadku nie ma problemu z pisaniem skryptów.
Ja muszę rozbudować mój hardware,dlatego jestem zainteresowany nową platformą.Mogę oczywiście kupić go w OC,ale lepiej wspierać rodzime pomysły.
Aplikacja jest robiona pod FSX więc ze światem komunikuje się poprzez Simconnect
Wiem,że Arek rozpoczął realizację kokpitu do Falcona,dlatego ma ten sam problem co ja.Czy przewidujesz jakąś aplikację pod ten sim?
ps.
Mickey81 mnie się wdaje,że Twoje rozwiązanie nie będzie działać.Najlepiej zrobić model i to sprawdzić,ja tak zawsze robię.
-
Mickey81 mnie się wdaje,że Twoje rozwiązanie nie będzie działać.Najlepiej zrobić model i to sprawdzić,ja tak zawsze robię.
Powinno działać :) robiłem tak już z przekaźnikiem. Z tym, że zza kondensatora wyprowadzałem bazę zwykłego tranzystora NPN, a w kolektorze była cewka przekaźnika i kłapało :) Dla pewności zrobię jednak model.
Skalarki: WOW!!!
-
Model będzie działał,problem jest z rozpoznaniem przez MJoy.Musisz połączyć Twój prototyp z MJoy następnie w SVMapper przypisać funkcje i sprawdzić czy działa jak toggle.
-
vito_zm Dziękuję za miłe przywitanie i dobre słowa na temat mojego projektu.
1.Czy projekt jest open tzn.dla wszystkich zainteresowanych.
2.Jeśli tak to czy możesz udostępnić schematy.Chciałbym porównać Twoje rozwiązanie z innymi projektami.
Rozumiem że chodzi ci o projekt I/O nie zaś o cały kokpit. Otóż w chwili obecnej nie mam żadnego problemu z udostępnieniem schematów. Same schematy dają obraz jak projekt będzie zrealizowany jednocześnie nie odkrywają tego co w tym najważniejsze czyli oprogramowanie procka i programu samej aplikacji. Moim zamysłem początkowo było stworzenie komercyjnej wersji w stylu Opencockpits ale obecnie nie jestem pewien czy mam na to wystarczające siły i środki, więc prawdopodobnie projekt skończy jako opensource dla każdego zainteresowanego (ale co do tego to decyzji jeszcze nie ma).
Jeśli chodzi o możliwości i skalowalność projektu to są one o wiele większe niż Opencockipts tylko że nie ma takiej potrzeby bo raczej nie widzę symulatora który potrzebuje więcej wejść/wyjść niż liczby które przytoczyłem w poście powyżej. Nie dodałem tam że będzie możliwe sterowanie również silnikami krokowymi.
Wiem,że Arek rozpoczął realizację kokpitu do Falcona,dlatego ma ten sam problem co ja.Czy przewidujesz jakąś aplikację pod ten sim?
Nie mówię tak i nie mówię nie. W chwili obecnej nie mam zielonego pojęcia co to jest FAST i inne tego typu hasła od których roi się na tym forum, ale jeszcze parę miesięcy temu tyle samo wiedziałem o simconnect. Lubię się uczyć i pokonywać nowe wyzwania - a to być może byłoby następne.
To byłoby tyle na razie, chętnie odpowiem na wszystkie pytania związane z projektem, ale proszę o wyrozumiałość za opóźnienia w odpowiedziach gdyż ostatnio zbyt dużo robię na raz. Schematy przygotuję w formie .pdf do końca tygodnia. Będą do pobrania z mojej stronki.
PS. A propos mojej stronki. Bardzo dawno jej nie aktualizowałem, cały wolny czas zżera projekt I/O dlatego między innymi nie znajdziecie tam ani słowa o tym o czy tera piszę. Ale wkrótce coś uaktualnię.
-
model zrobiony, przetestowany i działa :banan Wprowadziłem jednak kilka zmian. Wyjaśnię działanie na schemacie. Po podaniu napięcia za pomocą przełącznika następuje ładowanie kondensatora C1 poprzez rezystor R1. Czas ładowania w sekundach wyznaczamy ze wzoru T=R*C i możemy go dobrać do własnych potrzeb. Wartości ze schematu generują coś ok 0.5s, ponieważ na czas ładowania kondensatora ma wpływ rezystancja 'styków' klucza 4066. Przebieg napięcia na wejściu sterującym klucza (pin 13) oznaczyłem numerem 1. Ten krótki impuls wystarczy do chwilowego zadziałania klucza i wysterowania dowolnego wejścia mjoya typu pushbutton. Po przełączeniu w pozycję 2 kondensator rozładowuje się przez rezystor do masy układu. Proces ten obrazuje krzywa nr 2. Przełącznik jest niezbędny ponieważ kondensator przed ponownym załączeniem układu musi zostać rozładowany. W przeciwnym wypadku układ nie zadziała, gdyż naładowany kondensator będzie stanowił dla prądu stałego przerwę. Dioda Led została użyta do sygnalizacji zadziałania klucza.
(http://img38.imageshack.us/img38/8348/toggleswitchv20.th.jpg) (http://img38.imageshack.us/i/toggleswitchv20.jpg/)
Poniżej schemat połączeń układu docelowego, sprawdzonego z mjoyem.
(http://img5.imageshack.us/img5/7696/togglev2.th.png) (http://img5.imageshack.us/i/togglev2.png/)
-
Układ działa tak jak opisałeś tzn.generuje impuls na wyjściu 4066 w momencie załączenia przełącznika do pozycji 1.Rozumiem,że wyjścia podłączasz zgodnie z mapą od poz. 1 do 64.
Przełączniki dwu pozycyjne podłączane są wg.mapy od poz.65 do poz.94.Przełączniki te mają 2 pozycje on oraz off do których możemy przypisać funkcję sima typu on off.Np.poz.65 odpowiada załącz a poz.73 wyłącz jakąś funkcję zgodnie z SVMapper.
Jak chcesz to zrealizować Twoim układem.
-
Za pomocą drugiej sekcji przełącznika. Wtedy jeden 4066 obsłuży dwa przełączniki i wykorzysta dwa wejścia typu pushbutton. Oczywiście układ ma ograniczenie, jak opisałeś. Przez SVMapper nie zrealizuję mapowania funkcji off - to duży minus, ale niedużym nakładem pracy i kosztów mogę rozszerzyć możliwości mjoya. Pushbuttonów jest na tyle dużo, że nie powinno ich zabraknąć do realizacji innych funkcji kokpitu. Zresztą sam wiesz, że w razie czego można dorzucić drugiego mjoya ;) z tym, że pracującego w trybie ustawiającym na pierwszych pozycjach enkodery i toggle (chyba mode2, ustawiany zworką).
Jeśli masz jakąś propozycję usprawnienia tego rozwiązania, jestem otwarty na każde rozwiązanie, które może nam ułatwić zabawę w pitbuilding :)
Pozdrawiam
mickey81
-
Witaj skalarki !
Gratuluję projektu - naprawdę robi wrażenie :010:
Rzuciłem okien na "twojego" PIC18f4550. Ładnie się prezentuje - sprzętowe USB, obudowa DIP, zegar 48 MHz. Powiedz mi, dlaczego on ma jedynie 12 MIPS ? Jest to średnia, czy większość instrukcji zajmuje kilka cykli zegarowych? Czy odczyt stanu portu zajmuje jeden cykl, czy więcej? Jak zrealizowałeś obsługę tylu wejść i enkoderów? Czy tak wysoki zegar pozwala zwykły polling i key matrix ? W przypadku enkoderów przy szybkim kręceniu przesunięcie fazowe spada do kilkuset us (przy 500us i 512 wejściach masz ok. 48 cykli zegarowych na obsługę jednego, co przy średniej wydajności daje ok. 12 instrukcji uP bez uwzględnienia czasu na komunikację).
Rzuciłem okien na simconnect - to interface Microsoftu? Mógłbys w kilku słowach opisać ideę jego działania (zależności między modułami, interakcja ze sprzętem i symulatorem) ?
Czy są inne symulatory zgodne z tym interface'm ?
Czy aby posiadać SDK nie trzeba kupić bardziej "wypasionej" (droższej) wersji FSX'a ?
Ja ze swej strony będę kontynuować zabawę z Atmelami "just for fun".
Jeśli coś pominąłem to proszę uzupełnić.
Wydaje się, że uwzględniłeś wszystkie potrzebne czynniki. Ja jedynie zastanawiam się nad pozostawieniem na MB miejsca na drivery prądowe. W przypadku nie używania ich -można "zmostkować" odpowiednie nóżki. To pozwoli zachować to samo PCB MB dla różnych zastosowań
Jeszcze pytanie do Damosa - udostępnisz bibliotekę do bezpośredniego sterowania tymi urządzeniami ew. Tzn. protokół wykorzystywany przy komunikacji PC -> MB (USB) ?
Protokół będzie dość prosty i chyba będzie można go "upublicznić". Jednak wolał bym uniknąć sytuacji, kiedy inny soft komunikuje się się bezpośrednio ze sprzętem. Będzie wtedy ryzyko powstania wielu rozwiązań, które nie będą wzajemnie kompatybilne ze względu na bezpośrednie odwołania do sprzętu. A takie odwołania mogą sobie nawzajem przeszkadzać. Od tego jest warstwa abstrakcji w postaci softu, aby przez nią była realizowana komunikacja świata z hardware'm.
-
Jednak wolał bym uniknąć sytuacji, kiedy inny soft komunikuje się się bezpośrednio ze sprzętem. Będzie wtedy ryzyko powstania wielu rozwiązań, które nie będą wzajemnie kompatybilne ze względu na bezpośrednie odwołania do sprzętu.
To może nie bezpośrednio do sprzętu ale poprzez jakąś bibliotekę, którą będziesz używał do komunikacji z urządzeniami w usłudze systemowej/serwerze.
-
Jeśli masz jakąś propozycję usprawnienia tego rozwiązania, jestem otwarty na każde rozwiązanie, które może nam ułatwić zabawę w pitbuildin
Jest to najprostsze rozwiązanie i dlatego nie ma sensu komplikować układu.
-
Prawda? Nawet nie ma sensu robić innej płytki niż montaż na uniwersalnej.
Pozdrawiam
mickey81
-
Vito_zm to działa tak:
(http://img34.imageshack.us/img34/1117/toggleswitchv21.th.jpg) (http://img34.imageshack.us/i/toggleswitchv21.jpg/)
-
damos ... wiedziałem że poprzeczka powędruje bardzo wysoko ... straszna szkoda że nie zgrały się nasze procki, bo byśmy wymodzili coś odlotowego - czuję.
Zanim wyskrobię coś dalej muszę lojalnie uprzedzić: co prawda z zawodu jestem elektronikiem ale do zeszłego roku miałem bardzo długą przerwę w gmeraniu w tych sprawach. Jeśli chodzi o programowanie to całkowicie samouk. :002: Więc pewno na twoim poziomie to nie pogadamy ale wymiana rozwiązań i informacji na pewno się przyda.
Powiedz mi, dlaczego on ma jedynie 12 MIPS ? Jest to średnia, czy większość instrukcji zajmuje kilka cykli zegarowych?
Nie umiem dokładnie odpowiedzieć na to pytanie, ale z tego co się zorientowałem MIPS MIPSOWI nie równy i jak mi ktoś już to tłumaczył nie za bardzo da się porównywać procki tylko patrząc na ten parametr. jedno jest pewne jest to o wiele szybszy procek niż to co używa OC.
Wybór padł na ten procek głównie ze względu na duże możliwości we/wy, prostote w programowaniu, sprzętowe USB, sprzętowe SPI, sprzętowe I2C, 10 bitowe przetworniki A/D, gotowy USB stack od Microchipa wraz z driverami (nie HID) co daje o wiele szybszą transmisję przez USB.
Jak zrealizowałeś obsługę tylu wejść i enkoderów? Czy tak wysoki zegar pozwala zwykły polling i key matrix ? W przypadku enkoderów przy szybkim kręceniu przesunięcie fazowe spada do kilkuset us (przy 500us i 512 wejściach masz ok. 48 cykli zegarowych na obsługę jednego, co przy średniej wydajności daje ok. 12 instrukcji uP bez uwzględnienia czasu na komunikację).
Załączam schemat urządzenia, żeby było wiadomo o czym mówię - werja uproszczona do testów. (http://www.skalarki.co.uk/downloads/ioproject.jpg)
Widoczne są 3 bloki: wejścia, wyjścia oraz wyświetlacze 7-segmentowe.
Port B docelowo będzie sterował 4 grupami expanderów skonfigurowanych jako wejśćia oraz 4 grupami expanderów skonfigurowanych jako wyjścia.
Wszystko działa na szynie SPI, czyli wszystkie bloki są podłączone do SPI ale każdy blok ma oddzielną linię CS, dzięki czemu w jednej chwili można sterować konkretnym blokiem. Expandery MCP23S17 są o wiele lepszym rozwiązaniem od zwykłego rejestru SIPO ze względu na sprzętowe adresowanie oraz możliwość konfiguracji pinów jako wejśćia lub wyjścia, wewnętrzy PULL-UP oraz bardzo fajna rzecz: dwa piny sterowane z INTERRUPT ON CHANGE REGISTER. Każdy MCP w grupie ma osobny adres, co daje możliwość czytania i zapisywanie do konkretnego układu.
Enkodery są niczym innym jak tylko urządzeniami wykorzystującymi trzy piny wejściowe. Ponieważ adresowanie pozwala na dostęp do konkretnego expandera, jeśli podłączymy enkoder do pierwszego chipa można czytać z niego informacje z inną częstotliwością niż z innych wejść, co ma wpływ na wydajność urządzenia. Jeśli dobrze się doczytałem w założeniach Twojego projektu tutaj właśnie jest największa różnica. Zresztą co by tu nie kombinować pewno potrzebny będzie kompromis (w OC jest ograniczenie szybkościpracy encoderów) ale zobaczymy.
Ta sama zasada dotyczy wyświetlaczy 4 grupy po 4 MAX-y (na rysunku są trzy bo taka akurat była potrzeba :002:) sterowane z wyjść portu B.
Rzuciłem okien na simconnect - to interface Microsoftu? Mógłbys w kilku słowach opisać ideę jego działania (zależności między modułami, interakcja ze sprzętem i symulatorem) ?
Otóż jest to interfejs dla developerów piszących aplikacje umożliwający odczytywanie i zapisywanie danych z FSX. Dzięki niemu mamy dostęp do wszystkiego co dzieje się w FSX. Bardzo fajną opcją jest możliwość pobierania danych z FSX tylko kiedy jakaś zmiana się pojawi, np. zamiast nonstop wysyłać KURS informacja wysyłana jest tylko wtedy gdy kurs zostanie zmieniony itp. FSUIPC wykorzystuje intensywnie simconnect do przetwarzania danych.
Czy są inne symulatory zgodne z tym interface'm ?
Niestety simconnect jest napisany specjalnie dla FSX.
Czy aby posiadać SDK nie trzeba kupić bardziej "wypasionej" (droższej) wersji FSX'a ?
SDK było dostępne od pierwszej wersji FSX, ale potem były serwis-packi. Wszytko jest dostępne na oryginalnej płycie FSX-a z bibliotekami oraz gotowymi przykładami.
Może na tyle na razie bo się post - kobyła zrobił.
Chętnie powymianiam dalej wszelkie informacje. Damos - nie powstrzymuj się przed krytyką jeśli widzisz jakiś problem itp.
Pozdrawiam
-
damos ... wiedziałem że poprzeczka powędruje bardzo wysoko ... straszna szkoda że nie zgrały się nasze procki, bo byśmy wymodzili coś odlotowego - czuję.
Nic straconego :) Trzeba było się wcześniej ujawnić ;)
z tego co się zorientowałem MIPS MIPSOWI nie równy i jak mi ktoś już to tłumaczył nie za bardzo da się porównywać procki tylko patrząc na ten parametr.
MIPS to Mega Instructions Per Second. Innymi słowy - ilość milionów instrukcji assemblera wykonywanych w ciągu sekundy. Da się procki porównywać w-g tego parametru... Oczywiście - różne instrukcje mają różną ilość cykli zegarowych, ale jest pewna średnia typowa dla procka. Najczęściej podaje się, ile MIPSÓW dany procek "wyciąga" z 1 MHz. Widzę tutaj, że PIC ma około 0,25 MIPS z 1MHz. AVR32 ma ok. 1,32 MIPS z MHz. ATmega to ok. 1MIPS/MHz. Naturalnie - w konkretnym zastosowaniu ratio może się zmieniać. No i u ciebie jest sprzętowe USB :021: :010:
Najbardziej interesuje mnie, czy odczyt i zapis portów masz w jednym cyklu zegarowym - tzn: jeśli w pętli dasz na porcie wyjściowym zapis do niego 0, później 1 i tak w kółko - czy długość impulsu na wyjściu będzie równa 2 długościom impulsu taktowania uP ?
Wybór padł na ten procek głównie ze względu na duże możliwości we/wy, prostote w programowaniu, sprzętowe USB, sprzętowe SPI, sprzętowe I2C, 10 bitowe przetworniki A/D, gotowy USB stack od Microchipa wraz z driverami (nie HID) co daje o wiele szybszą transmisję przez USB.
To fakt - PIC ma lepszy support niż Atmel. :015:
Expandery MCP23S17 są o wiele lepszym rozwiązaniem od zwykłego rejestru SIPO ze względu na sprzętowe adresowanie oraz możliwość konfiguracji pinów jako wejśćia lub wyjścia, wewnętrzy PULL-UP
To zależy :)
1 - moje MBI mają wbudowaną regulację prądu dla wszystkich 16-tu kanałów
2 - cena... MCP23S17 znalazłem tylko w TME za... 8PLN sztuka (a ma tylko 16 pin). Za 8 PLN mam ponad 2 "moje" MBI - a one dają mi 32 porty OUT, więc wychodzi 2 razy taniej :) Za 10 PLN mam ATmege a ona ma 32 konfigurowalne porty i SPI i TWI i 6 ADC i PWM i .... :)
3 - MCP23S17 to adresacja, konfiguracja, SPI - bez zewnętrznego zegara - nieźle :)
oraz bardzo fajna rzecz: dwa piny sterowane z INTERRUPT ON CHANGE REGISTER.
:011: A do czego tego można użyć?
Każdy MCP w grupie ma osobny adres, co daje możliwość czytania i zapisywanie do konkretnego układu.
I to jest duża zaleta. Masz większą szybkość akwizycji danych.
Enkodery są niczym innym jak tylko urządzeniami wykorzystującymi trzy piny wejściowe. Ponieważ adresowanie pozwala na dostęp do konkretnego expandera, jeśli podłączymy enkoder do pierwszego chipa można czytać z niego informacje z inną częstotliwością niż z innych wejść, co ma wpływ na wydajność urządzenia. Jeśli dobrze się doczytałem w założeniach Twojego projektu tutaj właśnie jest największa różnica. Zresztą co by tu nie kombinować pewno potrzebny będzie kompromis (w OC jest ograniczenie szybkościpracy encoderów) ale zobaczymy.
Rozumiem, że jeszcze nie masz oprogramowanych enkoderów? Szkoda :( Liczyłem na jakieś wnioski i timingi. Bez ograniczenia prędkości się nie obejdzie.
SDK było dostępne od pierwszej wersji FSX, ale potem były serwis-packi. Wszytko jest dostępne na oryginalnej płycie FSX-a z bibliotekami oraz gotowymi przykładami.
Hhhhmm... a co powiesz np. na to:
http://www.fsdeveloper.com/forum/showthread.php?p=21067
The FSX SDK is currently only available by purchasing FSX Deluxe. I am not aware of any plans to change that.
there is no upgrade path from Standard to deLuxe so you would have to buy the deLuxe version at full price to get the SDK.
Chętnie powymianiam dalej wszelkie informacje. Damos - nie powstrzymuj się przed krytyką jeśli widzisz jakiś problem itp.
Problem? Problemem może się okazać szybkość odczytu expanderów w przypadku obsługi enkoderów. Jednak to jedynie kwestia ograniczeń na prędkość tych drugich. Jeśli expandery mają sprzętowy, szybki SPI - to powinny dać radę. jeszcze jedno Enkoder można traktowac jak urządzenie wykorzystujące 2 a nie 3 piny wejściowe. Wystarczy ustawić pull-up na wejściach a środkowy pin enkodera do masy. Wtedy jeden expander zamiast 5-ciu obsłuży ci 8 enkoderów.
BTW - zdradź, jakie układy zastosowałeś do sterowania 7-seg. :) Jest gotowy hardware do multiplexowania 7 seg?
-
ok - jest taki hardware... (MAX 7219) ale 35 PLN za sterowanie 8-mioma segmentami to przesada :( http://www.seguro.pl/sklep/?zobacz=3185&producent=
-
Przejrzałem schemat jest interesujący.Klasyczne rozwiązanie sterownika z zastosowaniem nowoczesnej technologi.Nie wchodziłem w szczegóły układu MPC 23S17,ale już z schematu widać jakie ma możliwości.Jedną z zalet tego rozwiązania jest to,że karta realizuje sprzętowo sterowanie wyjściami oraz wejściami.
Generalnie o projekcie będzie decydowało oprogramowanie.Hardware można zrobić lepiej lub gorzej,ale z punktu widzenia przyszłego użytkownika decydują możliwości softu oraz prostota jego stosowania.
Co do rozwiązań hardware to można to zrobić tak jak to robi OC i Damos tzn.zrobić dekompozycję (tak to się chyba nazywało).
OC ma może przestarzałą technologię,ale każdy nowy pakiet jest kompatybilny z starymi kartami.Modułowość związana z dekompozycją projektu daje elastyczność wyboru pakietów czyli ma wpływ na cenę.Jednocześnie możemy rozbudowywać projekt w zależności od potrzeb dokupując pakiety.Podobną filozofię przyjęli przy projekcie PHCC (viperpits) tzn.modułowość.
Moim zdaniem największą zaletą OC jest soft szeroko rozumiany.Mają dobre programy testujące hardware oraz SIOC,który reaguje na zdarzenia co jest jedną z jego zalet.Inną zaletą jest to,że przecięty użytkownik jest w stanie napisać potrzebny skrypt.Współpracuje z modułami FSUPC oraz XPLUPC.
W moim konkretnym przypadku jest przydatny ze względu na moduł FAST,który umożliwia współpracę SIOC z falconem.
FAST nie ma nic wspólnego z OC.
Jestem zwolennikiem rozwiązania Damosa z kilku powodów.Jego projekt jest modułowy,tzn.jest jądro MB w postaci uP,USB oraz wyjść (buforowanych).W zależności od potrzeb można połączyć do MB odpowiednią liczę potrzebnych DB.Daje to elastyczność wyboru oraz obniża cenę.Nie ma możliwości podłączenia wejść,ale to uzupełnia MJoy.
O wartości projetu i tak zadecyduje soft.
Dobrze,że mamy do wyboru kilka rozwiązań.W zależności od potrzeb można dokonać wyboru.Ostateczną weryfikacją będzie aplikacja tych projektów w symulatorach.Z mojego punktu widzenia każdy projekt będzie dobry jeśli będzie miał moduł programowy do komunikacji z falconem.
Wszystko w rękach programistów i tutaj może zaowocować współpraca naszych kolegów a szczególnie Damosa oraz Skalarki
pozdrawiam i życzę powodzenia.
-
Jestem zwolennikiem rozwiązania Damosa z kilku powodów.Jego projekt jest modułowy
Projekt Skalarki również jest modułowy i bardzo "sprytnie" pomyślany.
Nie ma możliwości podłączenia wejść
To też będzie :) Tutaj MPC niemal prosi o zastosowanie :)
O wartości projetu i tak zadecyduje soft.
Słuszna uwaga. Wydaje mi się, że będziemy w stanie stworzyć całkiem przyjazny użytkownikowi software.
Z mojego punktu widzenia każdy projekt będzie dobry jeśli będzie miał moduł programowy do komunikacji z falconem.
To akurat mogą załatwić gerrah lub codeking :)
-
Tutaj MPC niemal prosi o zastosowanie
Masz rację można o tym pomyśleć.Zwróć uwagę na ilość wyjść oraz wejść,gdybyśmy tylko stosowali wyjścia to i tak będzie kilka łączówek.Można pomyśleć o wyprowadzeniu sygnałów przez bufor do córki z układami MPC.Ja tak zrobiłem z Master z OC.Jeśli ktoś nie potrzebuje wejść to rezygnuje z DB.
-
oraz bardzo fajna rzecz: dwa piny sterowane z INTERRUPT ON CHANGE REGISTER.
A do czego tego można użyć?
Expander ma dwa rejestry po 8 bitów i dla każdego jest dodatkowy pin który zmienia stan jeśli np wystąpi zmiana na którymś z wejść. Więc wykorzystując ten pin można uzależnić wysyłanie danych zwrotnie do PC tylko gdy pin zmienił stan (czyli stan jakiegoś wejścia się zmienił).
Co do SKD simconnect to rzeczywiście masz rację. Ja od początku miałem wersję Deluxe. Potem kupiłem Acceleration więc myślałem że SDK było zawsze.
Problemem może się okazać szybkość odczytu expanderów w przypadku obsługi enkoderów. Jednak to jedynie kwestia ograniczeń na prędkość tych drugich. Jeśli expandery mają sprzętowy, szybki SPI - to powinny dać radę.
Te expandery mają sprzętowe SPI. Powiem w tajemnicy :004: że znam projekt wykorzystujący enkodery na tych expanderach i wszystko działa super bez widocznych opóźnień.
BTW - zdradź, jakie układy zastosowałeś do sterowania 7-seg. Jest gotowy hardware do multiplexowania 7 seg?
MAX7221 ze sprzętowym SPI, wiem że strasznie drogie ale dla mojego przypadku nadają się najbardziej, chyba że możesz zaproponować coś podobnego. Myślałem też żeby wyświetlacze wysterować multiplekserem ale dodatkowe elementy i dodatkowe programowanie PIC-a mnie zniechęciły.
Stosując MAX-y mam dostęp do każdej cyferki w dowolnej chwili i nie muszę zapisywać wszystkich 64 bitów za każdym razem jak chcę uaktualnić wyświetlacz.
Jestem zwolennikiem rozwiązania Damosa z kilku powodów.Jego projekt jest modułowy,tzn.jest jądro MB w postaci uP,USB oraz wyjść (buforowanych).W zależności od potrzeb można połączyć do MB odpowiednią liczę potrzebnych DB.Daje to elastyczność wyboru oraz obniża cenę.Nie ma możliwości podłączenia wejść,ale to uzupełnia MJoy.
Schemat, który przedstawiłem jest moją wersją roboczą robioną z myślą tylko i wyłącznie o moim Airbusowym kokpicie. W moim przypadku z przyczyn czysto praktycznych nie ma sensu rozdzielać go na wiele płytek, które tylko powodują plątaninę kabli. Jednak jak zauważył Damos rozłożenie wszystkiego na moduły nie stanowi żadnego problemu.
Dobrze,że mamy do wyboru kilka rozwiązań.W zależności od potrzeb można dokonać wyboru.Ostateczną weryfikacją będzie aplikacja tych projektów w symulatorach.
Ja ze swoim projektem nie mam ambicji konkurować z Damosem bo jak wiecie mamy kompletnie inne cele. Jest to tylko opcja do dyskusji nad rozwiązaniami sprzętowymi lub programowymi, bo niezależnie do czego to finalnie będzie podłączone to na odcinku PC USB - Procek, Procek - PC USB nie ma czego wiele wymyślać. Pakiet musi być wysłany i odebrany - KONIEC. A co z nim potem robi PC to inna historia, i tutaj będzie największa różnica.
Dobrze,że mamy do wyboru kilka rozwiązań.W zależności od potrzeb można dokonać wyboru.Ostateczną weryfikacją będzie aplikacja tych projektów w symulatorach.Z mojego punktu widzenia każdy projekt będzie dobry jeśli będzie miał moduł programowy do komunikacji z falconem.
Wszystko w rękach programistów i tutaj może zaowocować współpraca naszych kolegów a szczególnie Damosa oraz Skalarki
Niestety ja jestem kompletnie zielony w temacie Falcona więc na mnie raczej nie ma co liczyć póki co. Ale jeśli zakończę swój projekt to na pewno zajmę się czymś nowym - tylko że wtedy to może być już za późno bo jak widzę to wasz projekt pewno też będzie już gotowy.
Dobra, będzie tego na razie bo się nakręcam ... :002:
-
Jest to tylko opcja do dyskusji nad rozwiązaniami sprzętowymi lub programowymi, bo niezależnie do czego to finalnie będzie podłączone to na odcinku PC USB - Procek, Procek - PC USB nie ma czego wiele wymyślać. Pakiet musi być wysłany i odebrany - KONIEC
Masz rację,ja już widzę korzyść z tej dyskusji.Stosujesz bardzo nowoczesne elementy.Myślę,że Damos zgodzi się na modyfikację swojego schematu.Na dobrą sprawę to się już dublujemy.Ty już masz gotowy i sprawdzony projekt my dopiero go tworzymy.Jedyna różnica to uP i tutaj także masz przewagę (USB).Myślę,że możemy potraktować nasz projekt jak to podkreślił Damos jako praca dla przyjemności i z korzyścią dla budowniczych kokpitów.
Podziwiam Ciebie Skalarki za to,że będąc elektronikiem nauczyłeś się programować.Mnie się to nie udało,chociaż próbowałem.
-
Podziwiam Ciebie Skalarki za to,że będąc elektronikiem nauczyłeś się programować. Mnie się to nie udało, chociaż próbowałem.
Dzięki za uznanie, ale nie wiem czy się nauczyłem, uczę się. Elektronika cyfrowa fascynowała mnie od dawna. Jak 20 lat temu robiłem cyfrowy miernik na obronę pracy to to było coś!!!! urządzenie miało ze 20 scalaków - a teraz taki 1 PIC czy ATMEL rozwiązuje sprawę.
-
Mam prośbę do osób posiadających Falcon'a: zrobiłem prosty moduł odczytujący dane z Falcon'a i trzeba sprawdzić czy cały program, który wcześniej przedstawiałem działa. Niestety nie posiadam Falcon'a i nie mam nawet jak debugować :015:
Archiwum z programem jest pod linkiem http://angus.foxnet.pl/fs/DomowyKokpit.zip (http://angus.foxnet.pl/fs/DomowyKokpit.zip)
Prosty test: uruchomić program (plik DomowyPanelApp.exe), wczytać plik TestFalcon.hcps (przycisk Wczytaj...). Przejść na zakładkę "Moduły wejścia", wybrać z listy modułów "TestModule" i kliknąć na "Konfiguracja...". Przesunąć okno tak żeby widzieć główne okno programu, z listy "Profil" wybrać "Falcon" i kliknąć "Uruchom". Teraz należy włączyć Falcon'a i obserwować czy coś się zmienia w oknie "TestForm". Nazwy pól, których wartości powinny się zmienić: "form2:checkbox1" (informacja czy Falcon jest uruchomiony), "form2:checkbox2" (lampka MasterCaution), "form2:liczba1double" (liczba obrotów rpm), "form2:string1" (informacja o pozycji podwozia).
W pliku FalconData.xml (jest w katalogu /modules) można zmienić wersję Falcon'a (AF, OF itp.) oraz interwał czasu co ile odczytywane są dane z Falcon'a. Te dwa parametry opisane są w komentarzu.
Ważne: należy obserwować pierwszą zakładkę programu (zakładka "Log"). Jeśli pojawią się tam jakieś dziwne wpisy (np. po angielsku lub magiczne słowo "błąd") to proszę o podesłanie na priv zawartości tego pola tekstowego.
Jeśli coś jest niejasne to proszę pytać. Bardzo możliwe, że nie zadziała za pierwszym razem i konieczne będą poprawki - niestety sam nie mam jak sprawdzić (chyba, że te dane można odczytywać także z dema Falcon 4.0 - muszę to sprawdzić - a może ktoś wie ?).
Z góry dzięki za pomoc i czekam na (dobre?) wieści :001:
-
Witam
Na podstawie schematów Damosa zrobiłem przymiarkę do płytki MB
(http://img261.imageshack.us/img261/9481/newmb.th.jpg) (http://img261.imageshack.us/i/newmb.jpg/)
Pozdrawiam i proszę o uwagi
Zając
-
Bardzo ładny projekt! Małe poprawki już w drodze... :)
-
Expander ma dwa rejestry po 8 bitów i dla każdego jest dodatkowy pin który zmienia stan jeśli np wystąpi zmiana na którymś z wejść. Więc wykorzystując ten pin można uzależnić wysyłanie danych zwrotnie do PC tylko gdy pin zmienił stan (czyli stan jakiegoś wejścia się zmienił).
Aha.. stąd 2 wyjścia. teraz rozumiem. Czy układ może wtedy wysłać notyfikację po SPI, czy trzeba "odpytać" te dwa wyjścia?
Te expandery mają sprzętowe SPI.
Wiem. Jest nawet ich wariant ze sprzętowym I2C 1,7 Mbps :)
Powiem w tajemnicy :004: że znam projekt wykorzystujący enkodery na tych expanderach i wszystko działa super bez widocznych opóźnień.
Opóźnienia to nie problem. Dla człowieka 50 ms jest niewidoczne, dla procesora to połowa wieczności ;) Ja myślałem o gubieniu impulsów.
MAX7221 ze sprzętowym SPI, wiem że strasznie drogie ale dla mojego przypadku nadają się najbardziej, chyba że możesz zaproponować coś podobnego. Myślałem też żeby wyświetlacze wysterować multiplekserem ale dodatkowe elementy i dodatkowe programowanie PIC-a mnie zniechęciły.
Stosując MAX-y mam dostęp do każdej cyferki w dowolnej chwili i nie muszę zapisywać wszystkich 64 bitów za każdym razem jak chcę uaktualnić wyświetlacz.
A mnie twój projekt zainspirował do zmiany sposobu sterowania 7-seg :) Już go wstępnie opisałem Zającowi. Zastosuję ATmega8 (5 PLN) + ULN2003 (0,6 PLN), wszystko na I2C eerrmm... tzn TWI (I2C jest nazwą zastrzeżoną i Atmel się nie przyznaje, że jego TWI to faktycznie I2C :) ) Mam tam sprzętowe TWI ;) (400 Kbps). Atmega będzie multipleksować maks 7 szt. 7-seg LED o wspólnej katodzie i odbierać dane z mastera. Sterowanie każdą z cyfr z osobna - bez problemu. Na TWI mogę zaadresować 128 takich modułów (128 takich wyświetlaczy po 7 znaków - adres 7-bitowy). Expandery microchip'a mają adresy bodaj 3-bitowe (max 8 do zaadresowania). Nie wiem, jak z MAX'ami. Cenowo z pewnością będzie lepiej (6 PLN vs 40 PLN, przy 6-ciu sztukach to już ponad 200 w kieszeni ). Roboty - więcej :) Jednak skalowalność również będzie większa.
Ja ze swoim projektem nie mam ambicji konkurować z Damosem bo jak wiecie mamy kompletnie inne cele.
A po co od razu konkurować? Nie lepiej sobie "powspółpracować" ? :)
W PL mamy gorszy dostęp do układów microchipa niż w UK i w dodatku są drogie. Twój PIC to u nas jakieś 37 PLN. ATmega16 to 8-9 PLN. Jeden MCP23S17 jest w cenie ATmega16, która ma 2 razy więcej portów i w dodatku może mieć własny kod do wstępnej obróbki danych (takie dwa MCP23S17 "na sterydach" i w dodatku programowalne).
Jak tak dalej będziemy się "stymulować" to zrobimy cały kokpit za 60 PLN ;)
-
Jak tak dalej będziemy się "stymulować" to zrobimy cały kokpit za 60 PLN
I o to chodzi.Zakup podstawowego pakietu USB Expansion jako kit z przesyłką to około 200zł.Do tego zakup Master itd.Dlatego własny projekt na dostępnych elementach oraz z możliwością programowania w warunkach domowych (PC-LPT) ma uzasadnienie.
Współpraca przynosi już widoczne efekty to widać.Każdy z nas ma jakieś umiejętności,współpracując możemy odnieść sukces.Wracając do wspomnień to co stwierdził Skalarki jest prawdą.Dopiero na początku lat 90-ych miałem dostęp do zachodnich technologi i stare projekty można było realizować w jednym układzie Altery (PLD).
Zając moje gratulacje.
Codeking zabieram się do testów.Ostatnio walczę z uruchomieniem programu FalconGauges na nowym PC z ATI.Mam problemy i zabiera mi to trochę czasu.Myślę,że pokonam ten problem.Moje zmagania opiszę w oddzielnym wątku.Jest to też związane z budową kokpitu a konkretnie z MFD oraz CP.
-
Zastosuję ATmega8 (5 PLN) + ULN2003 (0,6 PLN), wszystko na I2C eerrmm... tzn TWI (I2C jest nazwą zastrzeżoną i Atmel się nie przyznaje, że jego TWI to faktycznie I2C :) ) Mam tam sprzętowe TWI ;) (400 Kbps). Atmega będzie multipleksować maks 7 szt. 7-seg LED o wspólnej katodzie i odbierać dane z mastera. Sterowanie każdą z cyfr z osobna - bez problemu.
Czegoś nie rozumiem - ULN2003 to "tylko" 7 wyjść więc nie będzie sterowania kropką ? Dobrze byłoby udostępnić sterowanie każdym segmentem oddzielnie. Zastosowałbym ULN2803. No i wyświetlacze ze wspólną katodą ? Coś mi nie pasuje do tego ULN (taki sam problem jak przy wyśweitlaczach LCD kilkanaście postów wcześniej). I ostatnia rzecz - max. 7 wyświetlaczy LED. Trochę mało jak na jeden układ. Można zastosować tani układ np. 74hc595 kaskadowo i zrobić np. 16 wyświetlaczy. Koszt będzie mniejszy niż zrobienie dodatkowego urządzenia dla tych 7 wyświetlaczy.
Jak coś pomyliłem to proszę o poprawkę :)
-
Czegoś nie rozumiem - ULN2003 to "tylko" 7 wyjść więc nie będzie sterowania kropką
Ten układ będzie pełnił rolę "sink" dla LCD-7seg..tzn.katoda LCD będzie podłączona do jednego z wyjść ULN2003.Czyli jeden układ może zapewnić sterowanie 7 LCD-7seg.Kropka będzie.Co do pozostałych pytań to lepiej to zrobi Damos.
-
vito_zm, orientujesz się może, czy FAF4 chodzi pod vistą?
pozdrawiam
mickey81
-
Moja rada unikaj visty.Może koledzy od Falcona wypowiedzą się na ten temat.
-
Niestety nie mam wielkiego wyboru, bo mam służbowy laptop z preinstalowaną vistą (to ten sam bez portu LPT :) )
Sugerujesz zakup kompa z winxp?
mickey81
-
Czegoś nie rozumiem - ULN2003 to "tylko" 7 wyjść więc nie będzie sterowania kropką ?
ULN (jak napisał vito_zm) nie steruje poszczególnymi segmentami a wspólną katodą. Sterowanie segmentami jest realizowane przez porty uP.
Dobrze byłoby udostępnić sterowanie każdym segmentem oddzielnie.
Tak właśnie będzie.
Zastosowałbym ULN2803.
On ma 8 wyjść. Też można, tylko, że to chyba "source" a nie "sink" driver? Płytki z samymi LED 7-seg, które pokazywał mi zając mają po 6 wyświetlaczy w jednym bloku... i są używane właśnie do kokpitów.
No i wyświetlacze ze wspólną katodą ? Coś mi nie pasuje do tego ULN (taki sam problem jak przy wyśweitlaczach LCD kilkanaście postów wcześniej).
Właśnie tutaj ten układ jest "u siebie". On "zwiera do masy" i tak ma robić: poprzez dołączenie wspólnej katody do masy "włącza " odpowiedni w danym momencie wyświetlacz. W LCD problem był zupełnie inny - tam potrzebowaliśmy symetrycznego bufora a nie jedynie "sink drivera"
I ostatnia rzecz - max. 7 wyświetlaczy LED. Trochę mało jak na jeden układ.
Jak coś pomyliłem to proszę o poprawkę :)
Pamiętaj, że tam będzie multiplexowanie - więc współczynnik wypełnienia spada nam wraz ze wzrostem ilości wyświetlaczy w jednym module (dla 6-ciu jest to max 16%, dla 16-tu to już zaledwie 6%). W tym rozwiązaniu chodzi o zredukowanie kabli na połączeniu sterownik<->płytka z wyświetlaczami. W "normalnym" wariancie ilośc przewodów (pinów na złączu) to: ilosc_LED7SEG*8+1, co dla 6-ciu daje złącze 49 pin. Dla 16-tu to już 129 pin. W wariancie multipleksowanym ilość połączeń to: ilosc_LED7SEG+8, co dla 6ciu daje złącze 14 pin. Zając twierdzi, że jest to istotne z punktu widzenia budowniczego kokpitu - po drugiej stronie maskownicy jest bardzo mało miejsca i nie można zmieścić na tej samej płytce sterownika i wyświetlaczy. Redukcja ilości przewodów połączeniowych też jest bardzo korzystna. Na koniec - jego rozwiązania (OC ?) korzystają z zespołów po 6 cyfr w linii i to podobno z powodzeniem wystarcza.
Można zastosować tani układ np. 74hc595 kaskadowo i zrobić np. 16 wyświetlaczy. Koszt będzie mniejszy niż zrobienie dodatkowego urządzenia dla tych 7 wyświetlaczy.
To akurat IMHO nie ma sensu. W moim rozwiązaniu do sterowania LED układ MBI ma to, co 74595, ale dodatkowo: 16 zamiast 8 wyjść, sterowanie prądem zasilania każdej diody, co eliminuje konieczność stosowania wielu rezystorów ograniczających. Na płytce z wyświetlaczami 7-SEG po prostu nie ma na nie miejsca a łączenie osobnej płytki z nimi wymaga ogromnej ilości kabli.
-
Mickey81 jeśli myślisz o kokpicie do Falcona oraz Hotas Cougar to tylko XP.Jest to dla mnie tak oczywiste (na podstawie opinii z viperpits),że się nad tym nie zastanawiałem.Tak jak wspomniałem koledzy falkonowcy na pewno wyrażą swoją opinię,bądź cierpliwy.
Codeking myślę,że Damos dokładnie odpowiedział naTwoje wątpliwości.
-
ULN (jak napisał vito_zm) nie steruje poszczególnymi segmentami a wspólną katodą. Sterowanie segmentami jest realizowane przez porty uP.
Tak, o tym pisał też vito_zm. Myślałem o trochę innym rozwiązaniu, stąd moje pytania.
Właśnie tutaj ten układ jest "u siebie". On "zwiera do masy" i tak ma robić: poprzez dołączenie wspólnej katody do masy "włącza " odpowiedni w danym momencie wyświetlacz. W LCD problem był zupełnie inny - tam potrzebowaliśmy symetrycznego bufora a nie jedynie "sink drivera"
Jak wyżej.
Pamiętaj, że tam będzie multiplexowanie - więc współczynnik wypełnienia spada nam wraz ze wzrostem ilości wyświetlaczy w jednym module (dla 6-ciu jest to max 16%, dla 16-tu to już zaledwie 6%).
Czyli chodzi o to, że wyświetlacze w pewnych momentach (procek zajęty komunikacją) mogłyby się "zamrozić" na chwilę lub mrugać ?
W tym rozwiązaniu chodzi o zredukowanie kabli na połączeniu sterownik<->płytka z wyświetlaczami. W "normalnym" wariancie ilośc przewodów (pinów na złączu) to: ilosc_LED7SEG*8+1, co dla 6-ciu daje złącze 49 pin. Dla 16-tu to już 129 pin. W wariancie multipleksowanym ilość połączeń to: ilosc_LED7SEG+8, co dla 6ciu daje złącze 14 pin.
Czyli na płytce ze sterownikiem będzie tylko jedno/dwa złącza do płytki z samymi wyświetlaczami ? Jeśli tak to przydałaby się płytka, w której zamiast miejsca na wyświetlacze były gniazda do podłączenia pojedynczych wyświetlaczy (chyba mogą się gdzieś przydać np. dwa obok siebie i nie będzie miejsca na płytkę z 6-ścioma).
To akurat IMHO nie ma sensu. W moim rozwiązaniu do sterowania LED układ MBI ma to, co 74595, ale dodatkowo: 16 zamiast 8 wyjść, sterowanie prądem zasilania każdej diody, co eliminuje konieczność stosowania wielu rezystorów ograniczających.
Jaki dokładnie to jest układ ?
Dzięki za szczegółowe odpowiedzi :) Jak jestem upierdliwy to przepraszam, elektronika ma wiele tajemnic przede mną - kilka chciałbym poznać :)
-
Czyli chodzi o to, że wyświetlacze w pewnych momentach (procek zajęty komunikacją) mogłyby się "zamrozić" na chwilę lub mrugać ?
Multiplexowanie polega na cyklicznym zapalaniu jednego wyświetlacza z pewnej puli. Reszta w tym czasie jest wygaszona. Może to spowodować: słabsze świecenie. Miganie, zamrożenie na chwilę (wtedy inne gasną) nie powinno mieć miejsca.
Czyli na płytce ze sterownikiem będzie tylko jedno/dwa złącza do płytki z samymi wyświetlaczami ?
Tak
przydałaby się płytka, w której zamiast miejsca na wyświetlacze były gniazda do podłączenia pojedynczych wyświetlaczy (chyba mogą się gdzieś przydać np. dwa obok siebie i nie będzie miejsca na płytkę z 6-ścioma).
Mniejsze moduły też można zrobić. To nie problem.
Jaki dokładnie to jest układ ?
MBI5026
-
Czyli chodzi o to, że wyświetlacze w pewnych momentach (procek zajęty komunikacją) mogłyby się "zamrozić" na chwilę lub mrugać ?
Uzupełnię przykładem.Zrobiłem w moim kokpicie 2 karty w pierwszej mam 16 LED-7seg.Czyli muszę wyprowadzić z karty sterującej wyświetlacze do każdego LCD 7 lub 8 (z kropką)przewodów 16x8=128 przewodów.W drugiej karcie mam inne rozwiązanie to które chcemy zastosować w naszym projekcie.W tym rozwiązaniu potrzebujemy 7 lub 8(z kropką)przewodów,które są wspólne dla wszystkich LED-7seg.,dodatkowo każdy wyświetlacz ma jeden przewód jako "sink" podłączony do katody.Widać na tym przykładzie korzyść dotyczącą ilości przewodów.
Nic nie jest za darmo,o tym pisał Damos.Trzeba cyklicznie zapalać (multipleksować)kolejne wyświetlacze.
-
Po konsultacjach z Damosem druga wersja płytki pcb do MB
(http://img209.imageshack.us/img209/8654/mbnew.th.jpg) (http://img209.imageshack.us/i/mbnew.jpg/)
pozdrawiam Zając
-
Miodzio, Zając! Robimy zbiorowe zamówienie?
Pozdrawiam
mickey81
-
W sprawie programu do sprawdzenia z Falcon'em: wiem w czym jest problem. Wieczorem (tzn. później :) ) wrzucę poprawioną wersję.
-
Codeking wysłałem zdjęcia z testu Twojego programu na priv.
Zajac moje gratulacje,piękna robota.
-
wstępna wersja płytki układu z multipleksowaniem:
http://www.damos.k11.pl/LO/led_avr/pcb_no_via_isp_all.png
płytka wielkości 4.3 cm x 3.6 cm
góra:
http://www.damos.k11.pl/LO/led_avr/pcb_no_via_isp_all_top.png
dół:
http://www.damos.k11.pl/LO/led_avr/pcb_no_via_isp_all_bottom.png
Jak znam życie - Zając to "dopieści" ;)
i schemat:
http://www.damos.k11.pl/LO/led_avr/schema_isp.png
Układ będzie kompatybilny z płytkami wyświetlaczy z FSBUS'a.
Na razie jeszcze nie ma do tego oprogramowania więc proponuję wstrzymać się z robieniem PCB :)
-
Bardzo ładny projekt.Damos dlaczego są dwa TW.Rozumiem,że zasilanie jest z MB na pin1,4 a sygnały na pin 2,3.
Codeking jak będziesz miał poprawiony Domowy kokpit daj znać.
PS
Czy można prosić o schemat MB zrealizowany na pcb Zajca.
-
Codeking jak będziesz miał poprawiony Domowy kokpit daj znać.
Wczoraj gdy miałem już paczkę gotową do wrzucenia na serwer to okazało się, że internet siadł. Dzisiaj wieczorem jak będzie internet to wrzucę, teraz nie mam możliwości bo siedzę w pracy.
-
Damos dlaczego są dwa TW.
TWI. Do jednego gniazda podłączasz kabel z MB lub "poprzedniej" DB. Do drugiego podłączasz następną DB.
Rozumiem,że zasilanie jest z MB na pin1,4 a sygnały na pin 2,3.
Dokładnie tak.
-
Oczywiście,zapomniałem,że DB są połączone równolegle.
Czy mogę prosić o schemat MB na podstawie którego Zajac wykonał pcb.
-
Damos jak rozwiązałeś identyfikację DB LED-7seg.W ramach córki DB sprawa jest oczywista.W połączonych równolegle DB już nie (zakładając transmisje danych w jednym kierunku-simplex).Jeśli jest to transmisja typu simplex to najprościej jest podłączyć pod wolne piny uP mikroprzełącznik adresujący DB (np.3 poz.dają 8 adresów).
-
Damos jak rozwiązałeś identyfikację DB LED-7seg.
Myślałem o tym :) Ciężko znaleźć miejsce na dip-switch'e:
(http://www.damos.k11.pl/LO/led_avr/atmega8_7SEG_isp_novia.PNG)
Zamiast tego będzie można (trzeba) zaprogramować ID DB po podłączeniu jej do MB. Każda DB będzie mieć domyślnie ID - 1. Po dołączeniu do MB będziesz mógł zmienić jej adres na inny (kolejny?). Każda DB będzie mogła wyświetlić swój numer (ID) na obsługiwanych 7-SEG. na takiej magistrali możemy umieścić do 128 DB, każda po max 7 LED.
Magistrala to I2C (TWI w terminologii Atmela), więc nie ma dodatkowego kabla CS do każdej DB. W TWI najpierw podajesz, do kogo wysyłasz dane a później ślesz same dane.
Czy mogę prosić o schemat MB na podstawie którego Zajac wykonał pcb.
Jak tylko uzgodnię z Zającem jak porozkładał piny na złączu :)
-
To nie ma problemu,ponieważ adres będzie zaszyty w uP.Muszę poczytać na temat I2C.
-
Poprawioną aplikację DomowyKokpit wrzuciłem na serwer pod adresem http://angus.foxnet.pl/fs/kokpit.html
@Damos - ustalanie ID płytki córki będzie ustawiane poprzez wgranie odpowiednio spreparowanego wsadu do uP czy może to będzie już taka "funkcja" w tych płytkach ?
-
Gratuluję Codeking.Na zdjęciach widać,że program widzi falcona.
(http://img190.imageshack.us/img190/246/testaf2.th.jpg) (http://img190.imageshack.us/i/testaf2.jpg/)
(http://img197.imageshack.us/img197/4182/testaf1.th.jpg) (http://img197.imageshack.us/i/testaf1.jpg/)
-
To jest bardzo dobra wiadomość :)
-
Damos - ustalanie ID płytki córki będzie ustawiane poprzez wgranie odpowiednio spreparowanego wsadu do uP czy może to będzie już taka "funkcja" w tych płytkach ?
Programowanie odpowiednio spreparowanego wsadu jest uciążliwe. Dlatego wybrałem opcję wspólnego wsadu z początkowym ID, które później można zmienić za pomocą odpowiedniej f-cji w "systemie".
-
jeśli ktoś chce miec jeszcze mniejsza płytkę - może zastosować uP w innej obudowie:
(http://www.damos.k11.pl/LO/led_avr/atmega8_7SEG_isp_small.PNG)
:karpik jakieś 47mmx29mm razem z otworami ;)
Przez weekend spróbuję zrobić układ multipleksujacy na TWI. (Ale na ATmega16 bo nie mam 8-ki)
-
Poczytałem na temat standaru I2C i muszę przyznać,że projekt DB dla LED7-seg.ma jedną ważną zaletę w porównaniu do innych rozwiązań.W budowanych kokpitach wyświetlacze są oddalone od siebie i umieszczone w różnych miejscach.Zastosowanie tego standardu przesyłania danych jest bardzo korzystne,ponieważ odbiorniki DB są połączone z nadajnikiem MB tylko po 4 przewodach.DB lokalnie rozprowadza w swoim otoczeniu sygnały do sterowania max. 7 LCD-7seg. i to w praktyce wystarczy do wyświetlenia jakiegoś parametru.
-
Trochę szkoda, że tylko 7 wyświetlaczy, gdyby było ich przynajmniej 10 (najlepiej 12) to byłoby tańsze rozwiązanie ze względu np. ktoś chce zrealizować pełny stos radia na tych wyświetlaczach. Częstotliwości wyświetlane są na 5 cyfrach (czasem daje się 6). Gdyby płytka obsługiwała 10 (lub 12) to jedno radio byłoby zrealizowane na jednej płytce. W obecnej sytuacji trzeba będzie dwa układy do jednego radia, w rezultacie min 3 dla dwóch (21 wyświetlaczy, 10 na radio (active + standby)). Gdyby ta płytka obsługiwała dwie płytki wyświetlaczy (takich jak dla FSBUS) to byłoby idealnie.
Próbował ktoś już oszacować koszty orientacyjne (z kosztami wykonania PCB) MB i DB ?
PS. Rozwiązanie bardzo mi się podoba, zwłaszcza pod względem możliwości rozbudowy, małego skomplikowania układów, interfejsu USB i niewielkich rozmiarów, i jestem pod wrażeniem zaangażowania osób tworzących (Damos, Zajac, vito_zm) a moje narzekania biorą się z tego, że osobiście chciałbym aby te rozwiązania były naprawdę dobre i dostępne absolutnie dla każdego. Proszę więc nie odbierać ich osobiście.
-
Poczytałem na temat standaru I2C i muszę przyznać,że projekt DB dla LED7-seg.ma jedną ważną zaletę w porównaniu do innych rozwiązań.W budowanych kokpitach wyświetlacze są oddalone od siebie i umieszczone w różnych miejscach.Zastosowanie tego standardu przesyłania danych jest bardzo korzystne,ponieważ odbiorniki DB są połączone z nadajnikiem MB tylko po 4 przewodach.
To właśnie było przyczyną wyboru tego rozwiązania. Dodatkowo jeszcze większa odporność na zakłócenia i większa maksymalna długość linii.
Trochę szkoda, że tylko 7 wyświetlaczy, gdyby było ich przynajmniej 10 (najlepiej 12) to byłoby tańsze rozwiązanie ze względu np. ktoś chce zrealizować pełny stos radia na tych wyświetlaczach. Częstotliwości wyświetlane są na 5 cyfrach (czasem daje się 6).
Więc 7 wystarczy :)
Gdyby płytka obsługiwała 10 (lub 12) to jedno radio byłoby zrealizowane na jednej płytce. W obecnej sytuacji trzeba będzie dwa układy do jednego radia, w rezultacie min 3 dla dwóch (21 wyświetlaczy, 10 na radio (active + standby)). Gdyby ta płytka obsługiwała dwie płytki wyświetlaczy (takich jak dla FSBUS) to byłoby idealnie.
Pisałem już o fatalnym współczynniku wypełniania impulsu zapalającego w przypadku dużej ilości wyświetlaczy. Przy 21 wyświetlaczach każdy będzie się "palić" przez ledwie ok 4% czasu. Można zrobić jedną płytkę obsługującą więcej wyświetlaczy (np 2x8), ale nie ma ATmega8 tylko ATmega16 (kwestia ilości portów)
Próbował ktoś już oszacować koszty orientacyjne (z kosztami wykonania PCB) MB i DB ?
Im mniejsza płytka - tym mniejszy koszt. Stąd staram się aby DB były jak najmniejsze. Dlatego można pomyśleć o układach SMD :karpik Rezygnacja z montażu przewlekanego pozwala umieszczać elementy po obu stronach płytki. Mogę zrobić projekt takiej płytki.
Wcześniej podawałem koszt elementów skłądowych: ATmega8 to ok. 5-6 PLN, ATmega16 to ok 9-10 PLN. ULN2003 to ok. 1 PLN, rezystory i kondensatory niemal za darmo: komplet do DB za 2 PLN. Sumarycznie: części do DB 7SEG to ok. 10-13 PLN ?
-
Pisałem już o fatalnym współczynniku wypełniania impulsu zapalającego w przypadku dużej ilości wyświetlaczy. Przy 21 wyświetlaczach każdy będzie się "palić" przez ledwie ok 4% czasu.
Wystarczy 12 wyświetlaczy, to już by było ponad 8%. Przy odpowiedniej częstotliwości oko ludzkie nie zauważy żadnej różnicy.
Można zrobić jedną płytkę obsługującą więcej wyświetlaczy (np 2x8), ale nie ma ATmega8 tylko ATmega16 (kwestia ilości portów)
Tu jest miejsce na rejestr przesuwny (wspominałem o 74hc595), tylko wtedy pewnie trzeba by inaczej rozwiązać zasilanie wyświetlaczy.
Dlatego można pomyśleć o układach SMD :karpik
To już będzie chyba za trudne do montowania :)
Sumarycznie: części do DB 7SEG to ok. 10-13 PLN ?
Zwiększając płytkę o kilka cm2 i elementy za powiedzmy 2-3 PLN wyjdzie taniej niż dwie DB do wyświetlaczy LED.
-
Przy 21 wyświetlaczach każdy będzie się "palić" przez ledwie ok 4% czasu.
Codeking miej zaufanie do Damosa i do mnie.My już ten temat przerabialiśmy wcześniej,było to związane z realizacją mojego projektu wg.OC.Popatrz na str17 tego wątku.
http://www.il2forum.pl/index.php?topic=9985.240
Na zdjęciach widać przewody taśmowe,które sterują LED-7seg.Rozwiązanie Damosa jest optymalne.Jeśli nie wierzysz to zrób małe doświadczenie.Zbuduj generator o wypełnieniu 1 do 21 i steruj tym LED.Zobaczysz jaki będzie efekt.Na tym polega doświadczenie w projektowaniu elektroniki,że człowiek może unikać błędnych rozwiązań.
-
Codeking miej zaufanie do Damosa i do mnie.My już ten temat przerabialiśmy wcześniej,było to związane z realizacją mojego projektu wg.OC.Popatrz na str17 tego wątku.
To nie jest kwestia braku zaufania, możliwe, że mój brak wiedzy teoretycznej i praktycznej dot. elektroniki jest przyczyną narzekania i upierdliwych pytań. Ufam, że powstające płytki będą najbardziej optymalne do naszych zastosowań. Może lepiej nie będę się już wypowiadał na temat elektroniki, nie chcę psuć atmosfery.
-
Witam ponownie
Widzę że praca wre, aż buczy :banan
Mam pytanie: gdzie planujecie robić płytki? Czy macie jakąś sprawdzoną firmę? Ja mam kilka, które chciałbym zrobić i zastanawiam się gdzie je wysłać.
Taka sugestia dotycząca projektu.
Ja na początku też planowałem robić coś co będzie bardzo uniwersalne, tanie i teoretycznie proste w rozbudowie. Myślałem że będzie lepiej jak każdy użytkownik będzie mił możliwość konfiguracji itp. Ale po paru dyskusjach z potencjalnymi użytkownikami stwierdziłem że to nie ma sensu, bo dokładnie każdy w zależności do czego to chce podłączyć oczekuje czegoś innego i ma inne wymagania. Drugi powód jest taki, że jak użytkownikiem końcowym będzie ktoś kto wie o co w tym wszystkim chodzi (a takich jest 1%) to nie ma problemu. Natomiast wszyscy inni będą wrzodem na d.... projektanta zalewając go setkami maili dotyczącymi ustawień, konfiguracji i kto wie jeszcze jakich inny głupich problemów. Zrezygnowałem więc i zdecydowałem zrobić platformę PnP pod konkretny kokpit, w moim przypadku A320. Dlatego tak jak pisze codeking wyświetlacze będą zrealizowane w grupach pod konkretne odczyty, ekodery w grupach pod konkretny przyrząd itd z wejściami i wyjściami.
Nie jestem pewien czy dążenie do zmniejszania wielkości płytek i ich mnożenie w projekcie oraz wykorzystywanie najtańszych rozwiązań ma sens (widać to po projekcie OC jaki pisze vito_zm - jedna wielka płątanina kabli). Damos chyba się ze mną zgodzi, że ilość potencjalnych problemów i usterek rośnie lawinowo wraz ze wzrostem lliczby elementów projektu. Ostatnia rzecz, przecież jak ktoś wydał na zbudowanie kokpitu, zakup kompów, softu, projektorów etc. parę tysięcy to jakie ma znaczenie czy płytki będą kosztować zamiast 100 -200zł? a dla projektanta ma to zasadnicze znaczenie bo ma większy budżet i o wiele wiele większe możliwości.
Bez względu na wszystko podziwiam inicjatywę i życzę powodzenia.
-
Może lepiej nie będę się już wypowiadał na temat elektroniki, nie chcę psuć atmosfery.
Dobrze robisz,że się pytasz.Zasadą dobrego projektowania jest tzw.burza mózgów,które polega na tym,że w grupie jest ktoś kto zadaje "trudne pytania".Jest to bardzo ważne,ponieważ specjaliści od danego tematu np.projektowania układów elektronicznych wpadają w rutynę i nie dostrzegają innych możliwości.Nie psujesz atmosfery odwrotnie zmuszasz do ponownego rozpatrzenia problemu.Tak trzymaj.
Skalarki poruszył ważny problem.Dla mnie jako elektronika nie ma problemu jaki projekt będę realizował,ponieważ wiem jak działają układy elektroniczne.W tej sprawie ważna jest opinia ludzi nie związanych z elektroniką.Pytania zadawane na forum OC dla mnie były trywialne,ale dla pytających były problemem (np.odpowiedniki układów scalonych).
Szkoda,że na naszym forum jest tak mała grupa zainteresowana tym projektem.Duża grupa osób zrealizowała np.MJoy lub jakieś proste panele dla simów.Dobrze byłoby gdyby wyrazili swoją opinię.Z drugiej strony trzeba sobie odpowiedzieć na pytanie kto ma z tego projektu korzystać.
-
Sądzę, że więcej osób ten temat obserwuje z zapartym tchem, z podziwem dla wiedzy prowadzących liderów tematu, a nie odzywa się, bo o co tu pytać jak się nie jest 'co najmniej' rozeznanym w elektronice, o programowaniu układów nie wspominając.
Sam do takich 'gapiów' należę.
-
Sądzę, że więcej osób ten temat obserwuje z zapartym tchem, z podziwem dla wiedzy prowadzących liderów tematu, a nie odzywa się, bo o co tu pytać jak się nie jest 'co najmniej' rozeznanym w elektronice, o programowaniu układów nie wspominając.
Sam do takich 'gapiów' należę.
No to ja miałbym pomysł aby admin forum lub osoba uprawniona utworzyła ankietę, niech każdy zainteresowany dorzuci swój głos: Ile osób jest zainteresowanych tematem, czy byłbyś w stanie zbudować urządzenie z elementów, czy wolałbyś dostać gotowe i przetestowane urządzenie itp, etc. Taka ankieta dałaby dane dla obrania kierunku dalszych działań.
-
noker, czy jest szansa, żebyś wrzucił na stronę o mjoyu, projekt płytki enkoderów? Zając ma świetny manual, dobrze byłoby, mieć wszystko w jednym miejscu. Przekopywanie się przez kilkanaście (dziesiąt) stron forum w poszukiwaniu np schematu jest pracochłonne, a czas ten można by wykorzystać na montaż układu :)
Pozdrawiam
mickey81
-
noker, czy jest szansa, żebyś wrzucił na stronę o mjoyu, projekt płytki enkoderów?
Jesteśmy w trakcie... :)
No to ja miałbym pomysł aby admin forum lub osoba uprawniona utworzyła ankietę, niech każdy zainteresowany dorzuci swój głos: Ile osób jest zainteresowanych tematem
To Forum jest dość specyficzne (co nie znaczy, że złe - może lepiej iść na jakość niż na ilość) i mamy wąską grupę zainteresowanych. Nie wiem, ilu ludzi nasz "czyta". Nie jesteśmy site'm dedykowanym budowie kokpitów. Taka sonda może być mało reprezentatywna.
Szkoda,że na naszym forum jest tak mała grupa zainteresowana tym projektem.Duża grupa osób zrealizowała np.MJoy lub jakieś proste panele dla simów.
Nasz soft i hardware będzie się świetnie nadawać do realizacji prostych paneli ! :)
Mam pytanie: gdzie planujecie robić płytki? Czy macie jakąś sprawdzoną firmę? Ja mam kilka, które chciałbym zrobić i zastanawiam się gdzie je wysłać.
U nas jest to Gama w Warszawie.
Taka sugestia dotycząca projektu.
Ja na początku też planowałem robić coś co będzie bardzo uniwersalne, tanie i teoretycznie proste w rozbudowie. [...] to nie ma sensu, bo [...] wszyscy inni będą wrzodem na d.... projektanta zalewając go setkami maili dotyczącymi ustawień, konfiguracji i kto wie jeszcze jakich inny głupich problemów.
Cóż.. przyznaję, że o tym nawet nie pomyślałem :( jednak widzę światełko w tunelu polegające na zbudowaniu naprawdę elastycznego systemu konfigurowalnego software'm. Tak - utopia, ale mam ochotę spróbować :)
Nie jestem pewien czy dążenie do zmniejszania wielkości płytek i ich mnożenie w projekcie oraz wykorzystywanie najtańszych rozwiązań ma sens (widać to po projekcie OC jaki pisze vito_zm - jedna wielka płątanina kabli).
Ale właśnie my staramy się minimalizować ilość kabli :) W tym ma tkwić jedna z zalet.
Damos chyba się ze mną zgodzi, że ilość potencjalnych problemów i usterek rośnie lawinowo wraz ze wzrostem lliczby elementów projektu.
Oczywiście! :) Dlatego starałem się użyć TYCH SAMYCH elementów do jak największej liczby zastosowań (drivery serial-in parallel-out MBI).
Ostatnia rzecz, przecież jak ktoś wydał na zbudowanie kokpitu, zakup kompów, softu, projektorów etc. parę tysięcy to jakie ma znaczenie czy płytki będą kosztować zamiast 100 -200zł?
1 - dla kogoś, (takiego jak ja )kto nie chce wielkiego kokpitu może to być kwestia - budować czy zapomnieć? Różnica - 150 PLNz a hardware lub 750 PLN za hardware może mieć kluczowe znaczenie. Ja na przykład chcę mieć nieco klawiszy i wskaźników wyprowadzonych po za ekran. Ja nie potrzebuję HUD'a ani MFD. Minimalizacja rozmiaru płytki, standaryzacja płyty DB - pozwalają znacznie zmniejszyć koszty.
a dla projektanta ma to zasadnicze znaczenie bo ma większy budżet i o wiele wiele większe możliwości.
Chodzi właśnie o wyzwanie dla projektanta ! :) Jeśli robię to "for fun" a im trudniejsze zadanie - tym większy fun. Więc interesuje mnie trudne zadanie a nie łatwe :) A trudne zadanie to: jak za pomocą tanich rozwiązań zrobić niezłą platformę.
Wystarczy 12 wyświetlaczy, to już by było ponad 8%. Przy odpowiedniej częstotliwości oko ludzkie nie zauważy żadnej różnicy.
Tak, ale wtedy przez 11/12 (92%) czasu każdy pojedynczy wyświetlacz NIE BĘDZIE świecić (będzie zgaszony, bo w tym czasie świecą się i gasną kolejno - każdy z pozostałych 11-tu). To daje średnie natężenie światłą na poziomie 1/12 nominalnego (faktycznie 2 razy mniej z wielu względów). Tym samym każdy element świeci 24 razy słabiej niż normalnie - przy zasilaniu maksymalnym, dopuszczalnym prądem. Nie ma to wiele wspólnego z częstotliwością odświeżania - jak np. w monitorze i nie należy mylić tych zagadnień. Efektem ubocznym nie jest migotanie a słabe świecenie.
Tu jest miejsce na rejestr przesuwny (wspominałem o 74hc595), tylko wtedy pewnie trzeba by inaczej rozwiązać zasilanie wyświetlaczy.
Rejestry przesuwne mamy opanowane do perfekcji :) Niestety - one generują dużo kabli....
Zwiększając płytkę o kilka cm2 i elementy za powiedzmy 2-3 PLN wyjdzie taniej niż dwie DB do wyświetlaczy LED.
Policzmy, co trzeba dodać do płytki aby uzyskać więcej 7-SEg przy tej samej jasności (np. 21 wyświetlaczy zamiast 7 - tyle mogę zrobić na ATmega16):
- inny uP - droższy (ATmega16: + 4 PLN)
- dodatkowy rejestr przesuwny + 1 PLN
- dodatkowe złącza do płytki wyświetlaczy (2 dodatkowe, ale i tak były by potrzebne w innej DB = o PLN)
- dodatkowe oporniki ( ale i tak były by potrzebne w innej DB = o PLN)
- dodatkowa przestrzeń na płytce na złącze (+ 5 PLN ?)
- dodatkowa przestrzeń na płytce na uP (+ 4 PLN?)
co oszczędzamy:
- kondensatory blokujące (2 komplety - 2 PLN ?)
- ULN2003 (2 komplety - 2 PLN ?)
- płytka drukowana (powierzchnia 2 innych DB - ok. 34 PLN ?)
- złącza programowania (2 szt - 1 PLN ?)
- złącza przejścia do następnej DB (2 komplety - 2 PLN ?)
- taśmy łączące i wtyczki łączeń z DB (2 komplety - 4 PLN ?)
W efekcie mamy:
- dłuższe przewody do wyświetlaczy (wspólna płytka dla 3-ch modułów)
- bardziej skomplikowany kod obsługi
- większa płytka
- minimalne rozwiązanie droższe
oszczędzamy ok. 45 PLN płacąc dodatkowo 13 PLN
Zysk: 32 PLN na 3 zestawy po 7 LED.
IMHO warte rozważenia. :)
Zaraz...... właśnie przyszedł mi do głowy pomysł na sterowanie multiplexowane 16-tu zestawów 7SEG*7 za pomocą jednej DB i ATmega8 (32 zestawów za pomocą ATmega16). Wymagało by to:
- dodatkowego rejestru MBI na każde dwa zestawy ( 8*3 PLN = 24 PLN) (16 MBI w przypadku ATmega16)
- odpowiednika ULN2003, ale podającego VSS a nie GND i odpowiednią wydajność prądową :karpik
Koszt początkowy wzrośnie znacznie z powodu płytki, lecz nie będzie obowiązku instalowania wszystkich driverów MBI - można tylko tyle, ile się chce/używa. Odpadnie za to lutowanie 128 rezystorów ! :) W przypadku ATmega8 koszt dodatkowy to 24 PLN za MBI + 10 PLN za PCB a zysk (w porównaniu do bazowego rozwiązania) to... 15*(25 PLN - koszt części oraz PCB na każdą DB) = 375 PLN, dla Atmega16 to 700 PLN (32*25) :karpik
Wtedy jedna DB mogła by obsłużyć cały kokpit LED 7SEG :011: :012: :118:
Może lepiej nie będę się już wypowiadał na temat elektroniki, nie chcę psuć atmosfery.
Nie rób sobie jaj. Właśnie sprowokowałeś kolejną ideę zmniejszenia kosztów i ilości kabli :)
-
a moje narzekania biorą się z tego, że osobiście chciałbym aby te rozwiązania były naprawdę dobre i dostępne absolutnie dla każdego
Teraz widzisz jaką ważną rolę odegrałeś w tym projekcie.Nowy pomysł Damosa powstał dzięki Twojej inicjatywie.Za moment ja (jako laik w programowaniu )zadam Tobie "dziwne pytanie" i będzie podobna sytuacja.W ten sposób powstają dobre projekty.
Damos przeanalizuję Twój pomysł,ale już widzę,że jest dobry.
Myślę,że projekt jako całość z dobrze napisanym manualem będzie zrozumiały dla większości pitbuilderów.Będzie przypominał MJoy tylko z większymi możliwościami.
Zgadzam się z Damosem,że nasze forum nie jest dedykowane budowie kokpitów,ale jestem pewien,że ten projekt będzie tak popularny jak MJoy.Dlaczego?Ponieważ jest prosty w realizacji (montaż,uruchomienie,programowanie uP w domowych warunkach i będzie tani) oraz dzięki modułowości każdy będzie realizował ten fragment projektu,który aktualnie potrzebuje.
-
Czołem,
Panowie, śledzę ten wątek z wypiekami na twarzy :003:. Chętnie bym pomógł w Waszym projekcie, niestety moja wiedza na temat elektroniki jest dosyć ograniczona (jak na zaawansowanie tego projektu). Jednym słowem CZAPKI Z GŁÓW. Tworzycie coś niesamowitego.
Co do ludzi którzy śledzą temat - wierzcie mi, jest ich naprawdę spora ilość. Jeśli byli byście zainteresowani rozwiązaniami mechanicznymi (kompletny układ kołysek, wolanty, orczyki - także kopie oryginałów, zegary analogowe, układ z ForceFeedback) jestem do usług. Coś tam majsterkuję w wolnym czasie lecz zawsze brakowało mi elektroniki i softu do moich pomysłów. Może czas pomyśleć nad kompletnymi zestawami (simbuilt)?
Gorąco pozdrawiam!
-
Jako, ze wyjaśnienia na priv. dla vito_zm okazały się nie dość jasne - opiszę tu rozwiązanie, do wymyślenia którego "zmusił" mnie Codeking :)
Tutaj schemat - prawie gotowy. Podłączenie ponad 250 "odnóży" i pogrupowanie ich w bus'y przerosło, mój wolny czas :)
http://www.damos.k11.pl/LO/led_multiplex/schemat.png (uwaga - duży ! ;)
Gniazda po prawej- (nie podłączone do końca) są wyjściami do poszczególnych zespołów wyświetlaczy (dziwny układ wyjść to zachowana wsteczna kompatybilność z modułami z FSBUS'a). W każdym zespole jest 8 wyświetlaczy - bo UDN obsługuje tyle anod. Dodatkowo w każdym sezpole jest 8 wejść do poszczególnych segmentów świecących pojedynczego wyświetlacza LED - jak w normalnym rozwiązniu multiplexowanym (Zając i Vito będą wiedzieć o co chodzi). Taki "zespół" wyświetlaczy 7SEG mających osobne anody i połączone równolegle odpowiadające sobie segmenty nazwę "zespołem" (wyświetlaczy 7-mio segmentowych).
Jak na schemacie widać: uP steruje wspólnymi anodami za pomocą drivera prądowego UDN2982 (current - nie sink).
Wszystkie "zespoły" wyświetlaczy współdzielą ten sterownik: (a raczej są z niego sterowane)
- wszystkie pierwsze wyświetlacze w zespole są sterowane przez linię BA1 (buferred anoda 1)
- wszystkie drugie wyświetlacze w zespole są sterowane przez linię BA2 (buferred anoda 2)
- wszystkie trzecie wyświetlacze w zespole są sterowane przez linię BA3 (buferred anoda 3)
- wszystkie czwarte wyświetlacze w zespole są sterowane przez linię BA4 (buferred anoda 4)
- wszystkie piąte wyświetlacze w zespole są sterowane przez linię BA5 (buferred anoda 5)
- wszystkie szóste wyświetlacze w zespole są sterowane przez linię BA6 (buferred anoda 6)
itd - do ostatniego..
Oznacza to, że wszystkie "pierwsze" zapalą się w tym samym czasie, wszystkie "drugie" też razem (bo są sterowane z tego samego wyjścia IC5).
Teraz pora na pytanie - co spowoduje, że po podaniu plusa do wspólnej anody zapalą się jakieś segmenty na "zasilonych" wyświetlaczach?
Otóż... uP przed podaniem plusa na anodę wypełni danymi układy: IC1, IC2,IC3,IC4,IC6, IC7,IC8,IC10 - jest to 8 sztuk MBI5026.
Każdy z MBI ma 16 wyjść podzielone (logicznie, nie fizycznie) na dwie grupy po 8. Każda z tych grup obsługuje inny "zespół" zasilając jego "współdzielone" katody. Oczywiście - jak to wynika z idei multiplexowania w danym kwancie czasu w każdym "zespole" zaświecą się segmenty tylko jednego wyświetlacza - tego, który akurat będzie miał wysterowaną anodę.
Tak więc praca uP będzie polegać na:
1 - zapisaniu wszystkich rejestrów MBI.
2 - zgaszeniu poprzednio zasilonych anod
3 - zatrzaśnięciu danych w rejestrach MBI
4 - zapaleniu anod pod nowym indeksem (następny wyświetlacz w "zespole")
5 - powrót do punktu 1 w celu wyświetlenia danych na następnym wyświetlaczu.... i tak w kółko.
Na czym polega "odmienność" rozwiązania w stosunku do zwykłego multipleksowania jednego zespołu ? ;)
Otóż:
1 - wszystkie 8 rejestrów współdzieli sygnał zegarowy generowany przez uP (jedna nóżka uP na wszystkie układy)
2 - wszystkie 8 rejestrów współdzieli sygnał LE generowany przez uP (jedna nóżka uP na wszystkie układy)
3 - każdy z 8-miu rejestrów ma OSOBNĄ linię dla danych wejściowych (pin 2) - więc każdy ma osobny strumień danych wejściowych, podawanych szeregowo.
4 - wszystkie linie danych (DATA1-DATA8), sterujące poszczególne rejestry są podłączone do tzw. "PORTU 8-mio bitowego" w uP. Każdy bit w tym porcie to osobna "nóżka" uP (DATA1-DATA8). Ta "nóżka" to źródło danych wejściowych dla jednego z układów MBI.
5 - wszystkie 8 bitów na porcie ustawiam w ciągu 3 cykli zegarowych przepisując jeden bajt z pamięci (ta pamięć jest uprzednio wypełniona danymi odebranymi przez I2C) do tego właśnie portu. Powoduje to jednoczesne wystawienie danych do wszystkich 8-miu układów MBI - zyskujemy bardzo dużo na prędkości. Zauważcie, że nie ma znaczenia, czy sterujemy jednym ukłądem, czy 8-mioma, bo zapisuję i tak cały bajt (8 bitów).
6 - rejestry MBI mają wspaniałe "zatrzaski", które umożliwiają przygotowywanie nowych danych "w tle" podczas, gdy obserwatorowi prezentowane są poprzednio "zatrzaśniete" dane. Czas przygotowania nowych danych podczas świecenia poprzednio ustawionych danych pozwala na "rozżarzenie" się diod świecących bez generowania sztucznych pętli opóźniających (nie wiem, jaki jest czas reakcji LED'ów na podanie i odcięcie zasilania - jeśli na poziomie 0,5 ms to było by świetnie) .
7 - rejestry MBI mają wbudowane sterowanie (regulację) prądu dla każdego z 16 wyjść, co pozwala zrezygnować z lutowan rezystorów - (normalnie jest potrzebnych 8 rezystorów na każdy "zespół" w celu sterowania prądem każdego pola świecącego na wyświetlaczu 7SEG) - wystarczy jeden rezystor na każdy rejestr. (tzn. jeden rezystor na dwa zespoły)
8 - rejestry MBI mają 16 wyjść - więc każdy z nich "obsługuje" 2 "zespoły" wyświetlaczy LED (po 8 na każdy)
9 - rejestry MBI mogą pracować z zegarem 25 MHz, co grubo przerasta możliwości ATmegi :)
10 - wszystkie zespoły są sterowane w tym samym czasie - więc ich ilość NIE wpływa na jasność świecenia (współczynnik wypełnienia jest ten sam) ! Wpływ na jasność ma jedynie ilość cyfr w "zespole".
Dodatkowo zatrzaski pozwalają skrócić czas przełączania:
- zakładamy, że nowe dane są gotowe do zatrzaśnięcia, i numer nowej anody też jest już przygotowany - i wtedy
- wyłączamy "poprzednią" anodę (1 cykl zegarowy)
- zatrzaskujemy dane w rejestrach MBI (1 cykl zegarowy)
- włączamy nową anodę (1 cykl zegarowy)
Wtedy czas zgaszenia wszystkich wyświetlaczy to zaledwie 3 cykle zegarowe ! (przy 8 MHz to 0,38 us)
Koszt CPU to odczyt z pamięci i przepisanie danych do portu. Całą robotę odwalają rejestry MBI.
Tak więc za pomocą jednego uP ATmega8, 8-miu MBI5026, jednego UDN2982 i 8-miu rezystorów można obsłużyć 16 zespołów wyświetlaczy po 8 cyfr każdy (sumarycznie: 128 cyfr). W przypadku ATmega16 ilość tę można podwoić (albo 32 zespoły po 8 cyfr, albo 16 zespołów po 16 cyfr).
Ze wstępnych obliczeń wychodzi mi, że zegar 8MHz (wewnętrzny oscylator RC w uP) wystarczy z nawiązką.
Plusy:
- Układ jest bardzo podatny na rozszerzenia: ustawiając szeregowo rejestry MBI (np. do każdego już istniejącego dopinamy kolejny) możemy również podwoić ilość sterowanych wyświetlaczy (ATmega8 - 256 cyfr, ATmega16 512 cyfr). To wszystko dotyczy jednej DB. Takich płytek można podłączyć po I2C 120... (przy kaskadzie to nawet 262 000 cyfr) :karpik
- Oczywiście - nic nie stoi na przeszkodzie wariantu minimalnego: ATmega8, podłączamy tylko 1 układ MBI5026 a do niego tylko jeden "zespół" pokazujący (mający) tylko jeden wyświetlacz 7SEG (jedna cyfra) - to nadal będzie działać.
- można "załatwić" kokpit jedną DB
- Przy realizacji 16-tu "zespołów" po 8 lub mniej cyfr średni koszt części oraz PCB na jeden "zespół" to ok. 5-8PLN. Dużo taniej niż gotowiec za 40 PLN.
Minusy - jeszcze nie gotowe i nie przetestowane :)
vito_zm - czy teraz wyjaśniłem nieco składniej ? :)
-
Jestem pod wrażeniem. Zamiast 7 mamy 128 co wystarczy absolutnie na cały kokpit. Wszystko wygląda ok i nawet zrozumiałem o co chodzi :) Jeśli teoria sprawdzi się w praktyce to rewelacja. Gratuluje rozwiązania.
-
Witam,
moje gratulacje Damos.Twoje wyjaśnienia są precyzyjne.W celu potwierdzenia czy dobrze rozumiem idę pracy tego projektu zadam kilka pytań.
Wyświetlacze 7-seg.są pogrupowane w zespoły (wiersze),gdzie każdy wiersz ma 8 wyświetlaczy (kolumn).Czyli możemy sobie wyobrazić matrycę złożoną z 16 wierszy po 8 kolumn co daje 128 wyświetlaczy.
Z tego co napisałeś to kolejno są zapalane kolumny powodując zapalenie wyświetlaczy 7-seg.podłączonych do danej kolumny.To się zgadza z tym co napisałeś
Wpływ na jasność ma jedynie ilość cyfr w "zespole".
Przytoczę jeszcze jeden cytat i zadam pytanie
Tak więc praca uP będzie polegać na:
1 - zapisaniu wszystkich rejestrów MBI.
2 - zgaszeniu poprzednio zasilonych anod
3 - zatrzaśnięciu danych w rejestrach MBI
4 - zapaleniu anod pod nowym indeksem (następny wyświetlacz w "zespole")
5 - powrót do punktu 1 w celu wyświetlenia danych na następnym wyświetlaczu.... i tak w kółko.
Czy zapisujesz wszystkie MBI tzn.128 bit-ów?
Wszystko co napisałeś o zaletach tego rozwiązania potwierdzam.
-
Witam,
moje gratulacje Damos.Twoje wyjaśnienia są precyzyjne.W celu potwierdzenia czy dobrze rozumiem idę pracy tego projektu zadam kilka pytań.
Wyświetlacze 7-seg.są pogrupowane w zespoły (wiersze),gdzie każdy wiersz ma 8 wyświetlaczy (kolumn).Czyli możemy sobie wyobrazić matrycę złożoną z 16 wierszy po 8 kolumn co daje 128 wyświetlaczy.
Z tego co napisałeś to kolejno są zapalane kolumny powodując zapalenie wyświetlaczy 7-seg.podłączonych do danej kolumny.To się zgadza z tym co napisałeś
Dokładnie tak. Oczywiście - można budować dłuższe wiersze zestawiając z sobą kilka innych i wyjdzie tablica np. 8 wierszy po 16 kolumn lub 4 wiersze po 32 kolumny itd.
Czy zapisujesz wszystkie MBI tzn.128 bit-ów?
Muszę. To jest multiplexowanie - więc za każdym razem muszę "wystawić" dane dla całej zapalanej kolumny: 16 wierszy * 8 bitów każdy = 128 bitów.
Zacytowany przez Ciebie cykl pracy dotyczy zapisania jednego bitu Dla zapisania wszystkich bitów dla danej kolumny uP wykona 16 iteracji punktów 1-4.
-
Muszę przyznać Damos,że Twój projekt DB LED-7seg.jest rewelacyjny.Masz w porównaniu do OC lepszy stosunek wypełnienia impulsów zapalających anody o 50% oraz masz także o 50% więcej wyświetlaczy.
Myślę,że po wakacjach mogę zrobić instrukcję dla MB oraz DB.Jeśli będą gotowe programy do testowania DB to mogę także objaśnić jak to działa na przykładach.Oczywiście po korekcji Damosa oraz po sformatowaniu tekstu rys.itp.(nie mam do tego celu programu).
Mam teraz dużo problemów z aplikacją FalconGauges w nowym PC,dlatego nie zaproponowałem wykonania prototypu fragmentu schematu DB-7seg.Analizując ten schemat dochodzę do wniosku,że nie ma takiej potrzeby.Projekt jest zrobiony przejrzyście i nie ma powodu aby nie działał.
-
Muszę przyznać Damos,że Twój projekt DB LED-7seg.jest rewelacyjny.
Takie są skutki narzekania innych na pierwsze rozwiązanie :118:
Masz w porównaniu do OC lepszy stosunek wypełnienia impulsów zapalających anody o 50% oraz masz także o 50% więcej wyświetlaczy.
Ilość wyświetlaczy można jeszcze zwiększyć np. dwukrotnie przy nie zmienionym współczynniku wypełnienia. (A w przypadku ATmega16 - dodatkowo przy nie zmienionej prędkości)
Myślę,że po wakacjach mogę zrobić instrukcję dla MB oraz DB.Jeśli będą gotowe programy do testowania DB to mogę także objaśnić jak to działa na przykładach.
Świetnie, jednak jeśli chodzi o zawartość MB to zostało jeszcze kilka rzeczy do omówienia.
Mam teraz dużo problemów z aplikacją FalconGauges w nowym PC,dlatego nie zaproponowałem wykonania prototypu fragmentu schematu DB-7seg.
Ja zrobię prototyp (o ile uwierzycie, że u mnie to naprawdę zadziałało ;) ) Zając wysłał mi już płytki do 7seg kompatybilne z FSBUS'em. (Ich projekty są już w Gamie i można zamawiać nawet pojedyncze sztuki)
Analizując ten schemat dochodzę do wniosku,że nie ma takiej potrzeby.Projekt jest zrobiony przejrzyście i nie ma powodu aby nie działał.
dzięki za słowa uznani, ale praktyka mówi, że zawsze warto przetestować prototyp pod kątem:
- apetytu na prąd
- odporności na zakłócenia (maksymalna długość linii TWI (I2C) )
- jasności świecenia 7SEG (tu jest zawsze pole do manewru przy regulacji prądu w MBI. Ostatecznie można ustawić maksymalny prąd dla danego wyświetlacza i tym ratować jasność).
- szybkości działania
BTW - jest tu może ktoś, kto zna (chciał by poznać) Eagle i ma kilka chwil wolnego czasu? Szukam ochotnika do kontroli BUS'ów - czy nie pomieszałem numerów dla poszczególnych układów oraz pinów gniazd :) Benedyktyńska praca... A przed zaprojektowaniem PCB absolutnie konieczna.
-
Zając wysłał mi już płytki do 7seg kompatybilne z FSBUS'em. (Ich projekty są już w Gamie i można zamawiać nawet pojedyncze sztuki)
Jaką nazwę mają w Gamie te płyteczki, żeby było wiadomo, co zamawiać i jaki jest ich koszt?
Pozdrawiam
mickey81
-
Jaką nazwę mają w Gamie te płyteczki, żeby było wiadomo, co zamawiać i jaki jest ich koszt?
Są dwie wersje tych płytek na 5 i 7 wyświetlaczy 7-segmentowych. Jak dojdzie przesyłka do Damosa i sprawdzi on czy się nadają do naszego projektu to podam namiary do gammy na te płytki. Nie ma sensu ich zamawiać do momentu sprawdzenia czy są ok. Co do ceny to nie mam pojęcia - sam zamawiałem je razem z projektem więc było trochę drożej, ale można sprawdzić wymiary płytek to :
- 5 wyświetlaczy 40x20mm
- 3 wyświetlacze 24x20mm
Płytki dwustronne z metalizacją, soldermaską i opisami na jednej stronie. Są bardzo małe - potrzebowałem ich do małych "skrzyneczek". Oto ich projekty
3led (http://img177.imageshack.us/img177/3895/led3.th.jpg) (http://img177.imageshack.us/i/led3.jpg/) 5led (http://img41.imageshack.us/img41/8297/led5n.th.jpg) (http://img41.imageshack.us/i/led5n.jpg/)
pozdrawiam Zając
-
BTW - jest tu może ktoś, kto zna (chciał by poznać) Eagle i ma kilka chwil wolnego czasu? Szukam ochotnika do kontroli BUS'ów - czy nie pomieszałem numerów dla poszczególnych układów oraz pinów gniazd
Damos myślę,że to nie jest problem.Rozumiem,że jest to potrzebne dla Zajca do zrobienia pcb.Nie wiem jakie narzędzie stosuje Zajac,ale projektuje pcb ręcznie a nie automatycznie (tak sądzę),dlatego nie potrzebuje schematu dla automatycznego projektowania pcb.Mogę zrobić zestawianie co z czym połączyć dla projektu pcb.
ps
na schemacie brak IC9 myślę,że jest to pomyłka
-
Damos myślę,że to nie jest problem.Rozumiem,że jest to potrzebne dla Zajca do zrobienia pcb.
Ja zrobię projekt PCB. W Eagle jest autorouter.
Nie wiem jakie narzędzie stosuje Zajac,ale projektuje pcb ręcznie a nie automatycznie (tak sądzę),dlatego nie potrzebuje schematu dla automatycznego projektowania pcb.
Na płytce będą w sumie 522 nóżki do połączenia. Nie bądźmy sadystami :) To już nie nadaje się do ręcznego projektowania :) Ponadto w przypadku wprowadzenia zmiany Zając musiał by projektować od nowa :karpik
na schemacie brak IC9 myślę,że jest to pomyłka
Nie do końca. Był tam układ IC9 (ATmega), ale została mu zmieniona nazwa na IC0. Oczywiście można zmienić nazwy reszty ICx.
-
Ja zrobię projekt PCB. W Eagle jest autorouter.
Jeśli jest autoruter to wszystko jest jasne.Jeśli nie zgłosi się nikt do pomocy to postaram się nauczyć Eagla.Ja nadal walczę z GF,na razie bez powodzenia.
-
Jeśli nie zgłosi się nikt do pomocy to postaram się nauczyć Eagla.Ja nadal walczę z GF,na razie bez powodzenia.
jak nie będzie chętnych - sam to zrobię :) Ty kontynuuj nierówną walkę z GF :)
-
Płytki dwustronne z metalizacją, soldermaską i opisami na jednej stronie. Są bardzo małe - potrzebowałem ich do małych "skrzyneczek". Oto ich projekty
3led (http://img177.imageshack.us/img177/3895/led3.th.jpg) (http://img177.imageshack.us/i/led3.jpg/) 5led (http://img41.imageshack.us/img41/8297/led5n.th.jpg) (http://img41.imageshack.us/i/led5n.jpg/)
Jakieś niestandardowe wyświetlacze trzeba do tych płytek czy podstawki do wyświetlaczy ? Bo rozkład nóżek jest inny niż w typowych wyświetlaczach 7-seg.
-
Jakieś niestandardowe wyświetlacze trzeba do tych płytek czy podstawki do wyświetlaczy ? Bo rozkład nóżek jest inny niż w typowych wyświetlaczach 7-seg.
Jest to typowy rozkład. Typowy dla małych wyświetlaczy: http://download.maritex.com.pl/pdfs/op/LTS028R-ASBW.pdf
-
Jest to typowy rozkład. Typowy dla małych wyświetlaczy: http://download.maritex.com.pl/pdfs/op/LTS028R-ASBW.pdf
No tak. Dla wyświetlaczy 7mm bo 9mm wzwyż to już praktycznie inny rozkład. Trzeba uważać co się kupuje.
-
Witam,dopiero dzisiaj pokonałem moje problemy związane z programem FalconGauges.Opisałem to w wątku
http://www.il2forum.pl/index.php?topic=9985.new#new
Pomoc przyszła z dalekiej Australii.
Damos jeśli nikt się nie zgłosił do pomocy to jestem do Twojej dyspozycji.
-
Poszukuje przełącznika przechylnego on-off-on (coś jak http://www.sklep.avt.com.pl/p/pl/4823941/przelacznik+dzwigniowy+dpdt+on-on.html ) ale taki, który sam powraca do pozycji centralnej tzn. nie blokuje się w skrajnych położeniach (coś jak joystick). Chcę go wykorzystać do sterowania klapami w FS.
Drugie pytanie: czy ktoś wykorzystuje taki mikrostyk (z wbudowaną diodą LED) http://www.tme.eu/mikroprzelacznik-monostkwadrat_ramka-druk-led-bialy/arts/pl/a25/pb6133fal-1.html ? Jakie wrażenia i czy da się sterować diodą niezależnie od stanu przycisku (on-off) i czy można wymienić diodę np. na inny kolor ?
-
Poszukuje przełącznika przechylnego on-off-on (coś jak http://www.sklep.avt.com.pl/p/pl/4823941/przelacznik+dzwigniowy+dpdt+on-on.html ) ale taki, który sam powraca do pozycji centralnej tzn. nie blokuje się w skrajnych położeniach (coś jak joystick). Chcę go wykorzystać do sterowania klapami w FS.
http://www.tme.eu/przelacznik-dzwigniowy-dp3t-on-off-on/arts/pl/przelacz/prze038.html - (ON)-OFF-(ON) Jedna pozycja stabilna
i dwie chwilowe
Drugie pytanie: czy ktoś wykorzystuje taki mikrostyk (z wbudowaną diodą LED) http://www.tme.eu/mikroprzelacznik-monostkwadrat_ramka-druk-led-bialy/arts/pl/a25/pb6133fal-1.html ? Jakie wrażenia i czy da się sterować diodą niezależnie od stanu przycisku (on-off) i czy można wymienić diodę np. na inny kolor ?
Używałem nieco innego - diody nie dało się wymienić. Ten jest większy i może da się to zrobić? Sterowanie było rozdzielne ze stanem przycisku. Zgaduję, że tu będzie tak samo. Inne rozwiązanie nie ma sensu - po co zapalać/gasić diodę gdy jest zasłonięta przez palec?
-
http://www.tme.eu/przelacznik-dzwigniowy-dp3t-on-off-on/arts/pl/przelacz/prze038.html (http://www.tme.eu/przelacznik-dzwigniowy-dp3t-on-off-on/arts/pl/przelacz/prze038.html) - (ON)-OFF-(ON) Jedna pozycja stabilna
i dwie chwilowe
Chcę się upewnić, że to taki o jakim myślę więc jeszcze pytanie: czy po przechyleniu dźwigni w skrajną pozycję i puszczeniu jej - sama wróci do położenia centralnego ?
Używałem nieco innego - diody nie dało się wymienić. Ten jest większy i może da się to zrobić?
Przydałby się taki przeźroczysty i z diodą zieloną. Po naklejeniu odpowiedniej naklejki z folii z nadrukiem byłby całkiem fajny przycisk do paneli, odpada wtedy "rzeźbienie" przycisków np. z plexi.
-
Ja takie stosuję w kokpicie.Ma ozn. IC2401T1B1M1QE DP3T (ON)-OFF-(ON).Działa w ten sposób,że załącza odpowiednie zestyki w skrajnych położeniach.W pozycji środkowej są rozwarte.Dźwignia powraca do pozycji środkowej.
-
A polecacie jakieś encodery dostępne na tme.pl i dobrze działające z MJoy'em i płytką Encoder ? Najlepiej takie, które nie mają tych wyczuwalnych przeskoków no i kosztowały normalne pieniądze (max. 10 PLN za sztukę).
-
cytat Gerrah 15.06
Postaram się w tym tygodniu z powrotem wejść w temat programowania.
W związku z tym cytatem mam pytanie do Gerrah,czy jest postęp w tym temacie a konkretnie czy można już testować PFL w Falconie,jeśli nie to czy jest to może związane z problemem współpracy programów Damosa i Gerrah,czy problem jest gdzie indziej.
Ponieważ kończę testy FalconGauges oraz MFD Exporter to będę miał około 2 tygodni wolnego czasu do wyjazdu na wakacje,dlatego jeśli jest coś do sprawdzenia lub wykonania to jestem do dyspozycji.Później będę tylko obserwatorem na forum (około 4 tygodni).Damos ponawiam pytanie,czy mogę Tobie w czymś pomóc.
PS
Codeking ja kiedyś kupiłem w ciemno na Allegro dobre enkodery za około 5 PLN,ale było to dosyć dawno.Te kupione ostatnio są do wyrzucenia.
-
A polecacie jakieś encodery dostępne na tme.pl i dobrze działające z MJoy'em i płytką Encoder ? Najlepiej takie, które nie mają tych wyczuwalnych przeskoków no i kosztowały normalne pieniądze (max. 10 PLN za sztukę).
Ja kupiłem takie: http://cgi.ebay.co.uk/Rotary-Encoder-push-button-switch-with-2-bit-gray-scale_W0QQitemZ220403724239QQcmdZViewItemQQptZUK_BOI_Electrical_Components_Supplies_ET?hash=item335115efcf&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1688%7C240%3A1318%7C301%3A1%7C293%3A1%7C294%3A50 (http://cgi.ebay.co.uk/Rotary-Encoder-push-button-switch-with-2-bit-gray-scale_W0QQitemZ220403724239QQcmdZViewItemQQptZUK_BOI_Electrical_Components_Supplies_ET?hash=item335115efcf&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1688%7C240%3A1318%7C301%3A1%7C293%3A1%7C294%3A50) i są ok. Przeskoki są wyczuwalne w każdym enkoderze mechanicznym. Tylko enkodery optyczne nie mają przeskoków, ale one są b.drogie.
-
Miałem 2 typy mechanicznych enkoderów.Jeden był zbudowany w ten sposób,że obracając gałką nie było przeskoków (mechanicznych).Prawdopodobnie jest zrealizowany na podobnej zasadzie co potencjometry ślizgowe.I ten nie przekłamywał kodu przy obracaniu osią.
Natomiast drugi był inaczej zbudowany w sensie mechanicznym (mogę go rozebrać i zobaczyć) i w tym było czuć opór przy obracaniu osią (przeskok mechaniczny) i ten przekłamywał.
To nie musi być regułą, tak było tylko w moim przypadku.
-
Potwierdzam to, co napisał skalarki. Każdy enkoder mechaniczny będzie dawał "przeskoki". Większe lub mniejsze, ale będą. Ja kupiłem za jakieś 5-7 PLN, ale nie w TME.
-
A miał ktoś do czynienia z enkoderami firmy BOURNS ? Zamierzam kupić parę i zobaczyć jak się spisują w płytce encoder do MJoy (czekam jeszcze na instrukcje na stronie mjoy.googlepages.com do płytki encoder'ów).
-
Ja zrobię projekt PCB. W Eagle jest autorouter.
Na płytce będą w sumie 522 nóżki do połączenia. Nie bądźmy sadystami :) To już nie nadaje się do ręcznego projektowania :) Ponadto w przypadku wprowadzenia zmiany Zając musiał by projektować od nowa :karpik
Witam !!
Co do Eagle-a to kiedyś próbowałem a jakoś mi nie "leżał". Może jeszcze raz spróbuje :001:. Widzę, że jednak będzie jedna większa płytka, a może jednak zrobić mniejsze / w każdej części kokpitu nie są potrzebne wszystkie wyświetlacze, ale tylko kilka i w różnych miejscach - mniejsze płytki w różnych miejscach. /. Sam projektuje w programie SprintLayout bez autorutera ale daję sobie radę. Myślę, że na podstawie schematu, ewentualnie wstępnego projektu z Eagla, dał bym sobie radę. Co do zmian, jeżeli nie będą duże to powinno obejść się bez projektowania od nowa.
Co do płytek do wyświetlaczy to mogę zrobić nowy projekt / bardziej uniwersalny / - akurat koszt ich jest nieduży, bo są małe.
Przez parę najbliższych dni będę za granicą więc do projektu będę mógł wrócić po 15 lipca.
pozdrawiam Zając
-
Witam,
czekałem,aż ktoś to zauważy.Każdy projekt ma swoje zalety oraz wady.Projekt nr1 (pierwszy) miał podstawową zaletę o której wspomina Zajac.Zaleta polegała na tym,że można było umieścić DB w różnych miejscach kokpitu w zależności od potrzeby.Komunikacja pomiędzy MB oraz DB była tylko po 4 przewodach.Wada sterowanie 7 LED 7-seg. oraz rezystory.Można tę wadę usunąć modyfikując DB np.wprowadzając MBI 5026 zamiast ULN 2003.Będziemy mieli 16 LED 7-seg.
Zaletą projektu nr2 jest jego mała cena w porównaniu do nr1 przy założeniu,że realizujemy sterowanie 128 LED.
Jeśli założymy,że potrzebujemy tylko 7 LED to projekt nr1 bez modyfikacji będzie tańszy.
Pytanie czy 16 taśm kabli po 16 żył rozprowadzonych gwiaździście jest problemem w sensie rozprowadzenia po kokpicie.Gdyby przyjąć wersję zmodyfikowana nr2 to dla 128 LED będziemy mieli 8 taśm kabli po 16 żył rozprowadzonych szeregowo po kokpicie.
Moim zdaniem obydwa projekty są dobre.Każdy użytkownik będzie je oceniał indywidualnie pod kątem swoich aplikacji.
PS
Pytanie do Codeking oraz Gerrah.Czy jest szansa aby zrobić testy LCD dla PFL Falcona na bazie projektu Damosa?
-
Pytanie do Codeking oraz Gerrah.Czy jest szansa aby zrobić testy LCD dla PFL Falcona na bazie projektu Damosa?
Szansa będzie jeśli Damos udostępni jakąś bibliotekę do obsługi wyświetlaczy :)
-
Jak znam życie - Zając to "dopieści" ;)
(http://img17.imageshack.us/img17/8206/dbled7.th.jpg) (http://img17.imageshack.us/i/dbled7.jpg/)
Oczywiście to wstępny projekt, teraz pracuje nad wersja z większa ilością układów na jednej płytce, z mojego doświadczenia wynika, że najlepiej sprawdzają się układy x6 / 6 zestawów wyświetlaczy do MCP, 12 zestawów wyświetlaczy do PEDESTAL /.
Następne projekty też są już na tapecie, ale nie nadążam nad tempem pracy Damosa
pozdrawiam Zając
-
Moje gratulacje Zając,bardzo ładna płytka.
-
Moje gratulacje Zając,bardzo ładna płytka.
A ja ponarzekam - nie ma gniazda na programator od MJoy'a :) W sumie to można by już zrezygnować z niego przy tych płytkach bo nie mają już wiele wspólnego z MJoy'em, ale jakby się zmieściło...
-
A ja ponarzekam - nie ma gniazda na programator od MJoy'a :) W sumie to można by już zrezygnować z niego przy tych płytkach bo nie mają już wiele wspólnego z MJoy'em, ale jakby się zmieściło...
Jak nie ma jak jest. Czy gniazdo ISP to nie programowanie? :021:
-
Jak nie ma jak jest. Czy gniazdo ISP to nie programowanie? :021:
To jest złącze programowania, ale inne niż w MJoy'u. MJoy ma wersję "wykastrowaną". Normalnie złącze ISP powinno posiadać linie sygnałowe oraz "+" i "-" zasilania. Dobry programator dostosowuje poziom sygnałów sterujących do poziomu napięć zasilających. W przypadku braku obu poziomów napięć programator może odmówić współpracy. Zastosowane gniazdo jest zgodne ze standardem ATmela i zgodne ze wszystkimi programatorami do ATmega dostępnymi na rynku:
(http://www.damos.k11.pl/LO/led_avr/ATMEL_ISP.PNG)
Odpowiednio rozkładając piny - można do niego podłączyć programator MJoy'a. Odwrotnie się nie da - złącze z MJoy;a jest zbyt ubogie.
Złącze 6PIN jest relatywnie drogie i trudno je dostać. Złącze 10PIN jest bardzo popularne. Z tych powodów wybraliśmy z Zającem wariant złącza 10PIN.
Szansa będzie jeśli Damos udostępni jakąś bibliotekę do obsługi wyświetlaczy :)
Dajcie mi trochę czasu, proszę. Obecnie jestem przygnieciony "z(obo)wiązany" pracą... :icon_chomik-w-tasmiea_274: ;)
Widzę, że jednak będzie jedna większa płytka, a może jednak zrobić mniejsze - w każdej części kokpitu nie są potrzebne wszystkie wyświetlacze, ale tylko kilka i w różnych miejscach - mniejsze płytki w różnych miejscach.
Można. Można również umieścić kilka większych płytek. System nie jest ograniczony do jednej.
-
Witam wszystkich,
mam nadzieję że, w odpowiednim temacie zamieszczam to co chcę wam zaprezentować. Efekt mojej ponad dwumiesięcznej pracy. Jest to zalążek kokpitu F16. Centralna konsola, Hud Box, LH i RH. Nie jest to jeszcze gotowe ale Vito_zm przekonał mnie by już teraz pokazać wam to, co udało mi się wystrugać. Niebawem przyjdzie czas na uzbrojenie w elektronikę i mam cichą nadzieję że, będzie to wasz projekt. Mam już zaprojektowane MFD które będzie sterowane Mjoy ( pozdrowienia dla pana który to lutuje :004: ), ICP jest w fazie projektowania. Będzie oparty na karcie BU0836X http://www.leobodnar.com/products/BU0836X/ która została mi z prototypów innych symulatorów. RWR jest już gotowy, mam w planie zbudowanie analogowe gauges. Pozostaje kwestia wszystkiego co jest OUT czyli diody, kontrolki itp.
Na początek tyle.... jeśli ktoś ma jakieś pytania proszę pytać.
http://img6.imageshack.us/i/p4080366.jpg/
http://img5.imageshack.us/i/p4080364.jpg/
http://img6.imageshack.us/i/p4080363.jpg/
http://img7.imageshack.us/i/p4080370.jpg/
http://img444.imageshack.us/i/p4080367.jpg/
Pozdrawiam.
-
Świetna robota! Na czym wzorowałeś swoją konstrukcję? Masz jakieś konkretne plany lub rysunki?
Jestem w posiadaniu rysunku w CAD z rozrysowanymi panelami, jeśli ktoś reflektuje, chętnie się podzielę.
Pozdrawiam
mickey81
-
Jestem pełen podziwu... gratulacje :) walcz dalej ... będzie jeszcze piękniej.
mickey81 co do rysunków nie masz czasami w CADzie 747-400 albo chociaż wymiary wewnętrznych bibelotów?
-
Moje gratulacje EGHI.Udowodniłeś,że można w bardzo krótkim czasie zrobić tak dużo.Myślę,że będzie to zachętą dla tych,którzy się jeszcze nie zdecydowali na budowę kokpitu.Dodam od siebie,że EGHI zainspirował mnie do modernizacji mojego kokpitu.Uwierzyłem,że jestem w stanie przy pomocy prostych narzędzi i jego rad ulepszyć swoją konstrukcję.Na zdjęciach tego nie widać,ale HUD jest już uruchomiony i obraz jest bardzo dobrej jakości.Jesteśmy w kontakcie od paru tygodni i mamy nadzieję,że dołączą do nas następni koledzy.Mamy nadzieję,że koledzy od softu nam pomogę w realizacji projektu.Możemy na naszym forum zrobić zalążek własnego projektu sterowania symulatorów (hardware oraz soft).Pojawienie się kolegi EGHI może być impulsem dla falconowców.Dodam tylko,że jest on specjalistą od FS i potrafił w tak krótkim czasie opanować problemy związane z falconem.Jeszcze jedna uwaga,naszym forum interesują się już koledzy z innych państw co powino być dla nas zachętą do realizacji naszych pomysłów.
-
Jestem pełen podziwu... gratulacje :) walcz dalej ... będzie jeszcze piękniej.
mickey81 co do rysunków nie masz czasami w CADzie 747-400 albo chociaż wymiary wewnętrznych bibelotów?
Niestety, posiadam panele do F-16 w wersjo B30, ponieważ buduję kokpit oparty na tym samolocie
-
Rozumiem aczkolwiek szkoda ... tak czy siak dziękuję za odp.
ps idę wykonywać benedyktyńską prace... gięcie 98x2, lutowanie 98x2 ... reszta to pikuś ... pan pikuś ;)
-
Witam ponownie.
mickey,
wzorowałem się na kilku projektach z vipertis. Po analizie i małych korektach powstał mój projekt w CorelDraw. Mogę to udostępnić ale muszę zrobić porządek bo straszny w tym bałagan. Co do paneli to, pewien miły pan przesłał mi swój projekt, też w Corel. Nie operuje w CAD, nie mam tego narzędzia i nie mam pojęcia o tym programie. Pewnie kiedyś trzeba będzie to opanować.
Napisałeś "buduję kokpit oparty na tym samolocie". Na jakim jesteś etapie? może podzielisz się swoimi doświadczeniami?
vito_zm,
z tym specjalistą to lekka przesada :001:. Po kilku latach dłubaniny, tracenia kasy na nieudane wynalazki można nabrać małego doświadczenia. Prawdziwi fachowcy to moi znajomi którzy podobnie jak ja do niedawna , realizują kokpit A320. Zawiesiłem ten projekt do momentu powstania hangaru na sim. Ktoś mi to skutecznie blokuje ale cierpliwie czekam na ostateczne decyzje. Jako że wpadłem w nałóg budowania i nie mam zamiaru się z tego wyleczyć, postanowiłem zrobić coś mniejszego. Pomysł zrodził się przypadkiem. Dwaj emerytowani mechanicy Miga21 wpadli na genialny pomysł budowy sima pod ten myśliwiec. Niestety, po tym jak jeden z nich podarował mi na komunię Atari, z komputerami nie mieli nic więcej do czynienia. Znalazł się też napalony na strzelanie do migów znajomy, który szybciej od emerytów zrezygnował. Wziąłem wiec sprawę w swoje ręce, a Ci starsi panowie z "loży szyderców" raczą mnie swoimi uwagami :002:
seeb,
popytaj na forum Vatsim. Tam są fachowcy od "benków".
Pozdrawiam.
-
Niestety od 737-xxx znaczy wszelkiej maści ale nie ma nikogo od 747-xxx z tego co zauważyłem :(
-
Witam ponownie.
Mickey,
wzorowałem się na kilku projektach z vipertis. Po analizie i małych korektach powstał mój projekt w CorelDraw. Mogę to udostępnić ale muszę zrobić porządek bo straszny w tym bałagan. Co do paneli to, pewien miły pan przesłał mi swój projekt, też w Corel. Nie operuje w CAD, nie mam tego narzędzia i nie mam pojęcia o tym programie. Pewnie kiedyś trzeba będzie to opanować.
Napisałeś "buduję kokpit oparty na tym samolocie". Na jakim jesteś etapie? może podzielisz się swoimi doświadczeniami?
Pozdrawiam.
W założeniu miała to być replika kokpitu F-16, realizowana przy jak najmniejszym nakładzie finansowym, współpracująca możliwie sprawnie z FS-em oraz Falconem 4.0AF. Kiedy już zabrałem się do cięcia dech pod konstrukcję, obsadziłem fotel od opla i X52 od Saiteka, doszedłem do wniosku, że niezbędne są poprawki. Ponieważ dysponowałem starym, ale wciąż sprawnym monitorem 15" LCD, postanowiłem wykorzystać go jako część tablicy przyrządów. Dociąłem z plexi odpowiednią maskownicę (wtedy myślałem, że jest ok ;) ) i przystąpiłem do montażu. Efekt był niezły, więc zabrałem się za konsole. Całość wykonana była z cienkiej sklejki, szlifowanej, szpachlowanej i malowanej na szaro. Potem przyszedł czas na panele. Na warsztat poszły przeróżne stare klawiatury, pady, mysze, następnie godziny spędzone z lutownicą, płytkami. W tak zwanym międzyczasie próbowałem na własną rękę realizować układy przełączników, pushbuttonów itp. Jednak dopiero po odkryciu Mjoya i przestudiowaniu wątków na naszym forum, wszystko zaczęło funkcjonować jak należy. Skupiłem się na FSXie. Mjoye dały możliwość mapowania dowolnego klawisza, więc w zasadzie większość funkcji dostępnych w FSie odwzorowane miałem w kokpicie. Na dodatkowym monitorze wyświetlałem sobie potrzebne wskaźniki, na głównym widok z VC. Jednak po pewnym czasie zaczęły się przeróbki, które trwają do dzisiaj. Efekt jest taki, że kokpit jest rozbebeszony na czynniki pierwsze, a większość drewnianej konstrukcji skończyła jako opał :) Dodatkowo przestał przypominać replikę F-16, choćby ze względu na konieczność przeprojektowania konsolet, tak aby mieć pod ręką to jest najbardziej potrzebne, a resztę wyświetlać na monitorach. Z pierwotnego projektu pozostała koncepcja HOTAS i rozmieszczenie paneli po dwóch stronach fotela. Jednak się nie poddaję i w wolnym czasie (którego ostatnio mam bardzo mało) kreślę rysunki nowej konstrukcji, mam nadzieję, że lepszej.
BTW Konwersja CAD-> CDR nie stanowi dla mnie problemu, ponieważ użytkuję służbowo oba pakiety, także jestem do usług, jeśli potrzeba pomocy w tym zakresie.
Pozdrawiam
mickey81
-
mickey,
na jakimś konkretnym dodatku do FS oparłeś swoją koncepcje? Płatny, darmowy?
Ja też o tym myślę i zacząłem się dobierać do F-16 Fighting Falcon aerosoftu. Strasznie oporny na modyfikacje, ale Lago pod fs2004 już mniej i udało mi się trochę przerobić panel. CP, HUD i DED można otworzyć w osobnym oknie i w trybie okienkowym wyświetlić to na dodatkowych monitorach.
http://img189.imageshack.us/i/p3160291.jpg/
Ktoś już próbował udoskonalić Lago http://www.fotocreatives.nl/projects/LAGO_F-16_Update_Project/index.htm Na kilku screenach się skończyło i cisza.
U mnie działa to tylko na jednym kompie. Dwie karty graficzne dadzą możliwość rozbicia na 4 monitory.
Większy problem stanowi brak SDK w płatnych dodatkach. Jedyne wyjście na pozbycie się klikania myszą to Mause Macro w FSUIPC. To też jest ograniczone chyba ( nie pamiętam) do 15 macro i nie wszystko zadziała. Ale, mam zamiar pobawić się Key2Mouse. Zobaczymy co z tego będzie.
Jest więc szansa że, odpalę kokpit w F4 i prymitywnie w FS.
Pozdrawiam.
-
jedna mała prośba do zająca i damosa: przy projektowaniu tej płytki proszę uwzględnić złączkę ISP10 w obudowie ... bo kurcze w mjoyu16 nie mozna zamontować złączek w obudowach choć miejsce by się znalazło ale obudowa nachodzi na końcówki lutownicze diód
-
Zrobiłem na podstawie wymiarów EGHI kolumnę CP.Jest to model wykonany z tektury 2.5mm.Konstrukcja jest wzmocniona od wewnątrz listwami o przekroju kwadratowym.
Ze względu na małą powierzchnię przeznaczoną na kokpit chcę zrobić najpierw modele paneli z tektury 2.5 mm wzmocnionej listwami i sprawdzić ile zajmą miejsca.Później zrobić ewentualnie korekcję wymiarów,jeśli będzie to konieczne.Nie wiem jakie zastosuję LCD lub CRT,dlatego będzie możliwość zrobienia korekcji.
(http://img268.imageshack.us/img268/7962/dscn2382.th.jpg) (http://img268.imageshack.us/i/dscn2382.jpg/)
(http://img23.imageshack.us/img23/9416/dscn2383k.th.jpg) (http://img23.imageshack.us/i/dscn2383k.jpg/)
(http://img268.imageshack.us/img268/8088/dscn2386.th.jpg) (http://img268.imageshack.us/i/dscn2386.jpg/)
(http://img110.imageshack.us/img110/3443/dscn2387.th.jpg) (http://img110.imageshack.us/i/dscn2387.jpg/)
(http://img27.imageshack.us/img27/1333/dscn2388z.th.jpg) (http://img27.imageshack.us/i/dscn2388z.jpg/)
-
EGHI - :karpik szczena opada jak się takie coś widzi, a jak zapalisz "choinkę" to dopiero będzie efekt, (może zaprojektujesz jakieś małe panele uniwersalne dla cywilnych samolotów do FS'a :011: )
vito_zm - fajnie to wygląda, a ta tektura to dobry pomysł, na stronie http://www.drzewiecki-design.net/HomeCockpit.htm (http://www.drzewiecki-design.net/HomeCockpit.htm) można zobaczyć jak wykorzystać tekturę do budowy kokpitu Boeing'a :)
-
WOW :010: Panowie... wasze konstrukcje mechaniczne budzą mój podziw i szacunek :)
BTW - czy zamiast LCD/CRT nie było by lepiej/taniej kupić starego laptopa za 150 PLN, posadzić Linuxa, przepiąć mu ekran "na plecy" i tak zrealizować wyświetlanie ? (oczywiście - pozostaje problem software'u)
-
Wszystkie opcje są możliwe.Teraz kolej na rozeznanie tematu LD,CRT lub laptop pod kątem cen.
Pomysł na modernizację kokpitu jest związany z pojawieniem się nowego kolegi EGHI na naszym forum.To on zaraził mnie swoim optymizmem oraz udowodnił,że można zrealizować projekt w bardzo krótkim czasie nie będąc w temacie Falcon.Liczę na jego doświadczenie w tworzeniu konstrukcji.Dla mnie jest to największy problem.
-
vito,
świetna robota, wygląda znajomo :001:.
Polecam raczej LCD. Stare CTR są zbyt ciężkie, zajmują dużo miejsca. Jedyna zaleta to cena i w zimie dodatkowe ogrzewanie :001:. U mnie do dziś były zastosowane dwa 5 cali TV. Jeden właśnie został zastąpiony w HUD, wydłubaną matrycą z 7 calowego monitora TFT (o tym napiszę jak już wszystko perfekt zadziała).Drugi zastosowałem w RWR i tak zostawiam bo podoba mi się ten oldschool-owy radar.
codeking,
mam nadzieje że na św. Bożego Narodzenia choinka zaświeci i i zrzucę kilka bombek. :004:
damos,
myślałem o laptopach, nawet mam jakieś stare rupiecie. Ale tu nie o to chodzi, problem w tym że wymiary screena muszą być odpowiednie, bo jak widać mało tam miejsca. Najbardziej pożądane są 10,4 do CP, 4 do HSI ( ten już posiadam) i 6,4 do MFD. Cały czas poluję na Ebay, można trafić w dobrej cenie. Problem software jest już rozwiązany. Zaczynam planować PCB pod panele, pozostaje kwestia elektroniki. Prawdopodobnie będzie to OC, jeszcze nie zdecydowałem.
Pozdrawiam.
-
Zaczynam planować PCB pod panele, pozostaje kwestia elektroniki. Prawdopodobnie będzie to OC, jeszcze nie zdecydowałem.
Proponuję wstrzymać się z OC do czasu ukończenia projektu przez naszych mistrzów lutownicy (damos, vito, codeking, zając). Wszystko wskazuje na to, że projekt będzie lepszy niż OC, a ewentualny support masz na miejscu :)
Posiadam F-16 od Aerosoftu, ale nie jestem zadowolony do końca z tego zakupu. Tak jak wspomniałeś możliwości mapowania komend są wręcz żałosne, tak jak i pomoc techniczna. Zainteresowanych zapraszam tu: http://www.forum.aerosoft.com/index.php?showtopic=25599&st=0&p=159777&#entry159777
Myślę o bardziej uniwersalnym kokpicie, takim w którym polecę sobie myśliwcem, a jak mi się znudzi to przesiądę się w 737 :) Zobaczymy jak to wyjdzie w praktyce :)
EGHI, czy mógłbyś napisać coś więcej na temat działającego HUDa? Gdybyś jeszcze mógł podrzucić wymiary centralnej konsolki...
Vito_zm super pomysł z tym modelem :)
Pozdrawiam
mickey81
-
mickey,
mocno wierzę że, projekt kolegów znajdzie zastosowanie w moim wynalazku. Dlatego spokojnie obserwuje poczynania fachowców. Wiem też ile wolnego czasu trzeba poświęcić na pracę przy takim projekcie. Mi się nigdzie nie śpieszy, i nie zdecydowałem jeszcze czego użyję. OC i Fast jest już gotowe, dlatego jest to jedna z opcji.
Tak przy okazji.. panowie damos, codeking, vito i zając pytanie: czy byli byście w stanie zbudować coś, czym można sterować servo? bardzo zależy mi na analogowych gaugesach.
Co do HUD to, opiszę wszystko jak otrzymam przesyłkę z resztą elementów i poskładam wszystko. Cały czas walczę z podwójnym odbiciem które nieco drażni, ale da się z tym latać.
mickey przygotuję wymiary w cdr. Jak zrobię w tym porządek to podrzucę. Może przerobisz to w CAD?
Pozdrawiam.
-
Z konwersją CAD->Corel i na odwrót nie ma absolutnie żadnego problemu, proszę podsyłać pliki, a ja będę konwertował :)
-
Tak przy okazji.. panowie damos, codeking, vito i zając pytanie: czy byli byście w stanie zbudować coś, czym można sterować servo? bardzo zależy mi na analogowych gaugesach.
Tak. (jednak zbudowanie mechaniczne takiego zegara [np. 2-wskazówkowy altimeter z jedna wieloobrotową], choć jest w teorii proste - przerasta moje możliwości :karpik ja pozostanę przy elektronice i sofcie) Najpierw jednak muszę skończyć "Host Stage1" (najżmudniejszą część): oprogramowanie kontrolera hardware'u na PC i rdzeń MB na ATmega (nie wcześniej niż za dwa tygodnie). Później dodawanie kolejnych "features'ów" będzie dużo szybsze i przyjemniejsze. Po skończeniu "Host Stage1" chłopaki będą mogli robić swój własny soft do sterowania i nie będą musieli czekać na mnie.
-
Moje gratulacje Damos.Ty masz z nas najwięcej pracy,ale jest nadzieja,że Twój projekt będzie lepszy od komercyjnych projektów.
Tutaj jest przykład prostego analogowego gauges
http://www.viperpits.org/smf/index.php?topic=1581.105
Sterowanie zapewnia FAST oraz karta OC.
-
damos,
pisząc- coś czym można sterować servo, miałem na myśli właśnie elektronikę. Do której mogę podpiąć servo i sterować jakimś softem. Zbudowanie takiego zegara nie stanowi dużego problemu i mam już na to pomysł. Pytam tylko czy kiedyś tam ewentualnie, była by taka możliwość.
-
Tak swoją drogą FSUPIC do FS pozwala odczytywać też nachylenie w pionie i poziomie... co przy pomysłowości naszych forumowiczów mogło by się okazać, że ktoś będzie miał pomysł na sztuczny horyzont :) zapotrzebowanie na tani taki układ penie było by spore... ale tymczasem zajmij się może np wyświetlaczami :) na które sam czekam z utęsknieniem :)
-
Jakby kogoś interesowało, to pod linkiem http://angus.foxnet.pl/fs/kokpit.html zamieszczam wpisy dotyczące aplikacji, którą rozwijam, i którą mam zamiar wykorzystać do sterowania "rodzącymi" się na tym forum urządzeniami.
-
powinieneś także zainteresować się projektem openGC do wyświetlania różnych rzeczy na osobnych wyświetlaczach.
-
Dzięki Codeking za ten pomysł z opisem tego co robisz.Po dokładnym przeczytaniu będą miał do Ciebie pytania.Bardzo dobry pomysł i myślę,że nam pomoże zrozumieć jak tworzyć skrypty.
-
powinieneś także zainteresować się projektem openGC do wyświetlania różnych rzeczy na osobnych wyświetlaczach.
Szybki "rzut okiem" - wygląda ciekawie. Projekt zatrzymał się w 2006r, czyli albo jest już finałowy albo brakło zapału programistom. Trzeba się będzie temu bliżej przyjrzeć - może da się to wykorzystać. Dzięki.
-
Przeczytałem założenia do Twojego programu.Mam do Ciebie kilka pytań.
1.Czy my użytkownicy będziemy pisać skrypty pod nasze potrzeby?
2.Kto będzie tworzył moduły?
Pytanie dotyczy Falcona.Ma on pod konkretnymi adresami w share memory zapisane swoje zmienne.Autor programu FAST przypisał tym zmiennym konkretne nazwy.Piszący skrypt nie musi wiedzieć gdzie te zmienne są zapisane,zna tylko ich nazwę i wie co one oznaczają.
3.Czy Ty w jakimś "module,aplikacji?"przygotujesz dla nas zwykłych użytkowników coś podobnego?
Tyle na początek.
Czy można prosić o jakiś prosty przykład skryptu,aby wykonać testy.
Dla Falcona działa sam sprawdzałem.
-
1.Czy my użytkownicy będziemy pisać skrypty pod nasze potrzeby?
Tak, każdy tworzy sobie skrypty takie jakie chce, wiadomo, że jeśli wypracujemy wspólnie jakiś projekt panelu (np. autopilota) to skrypt będzie ten sam :) Ale ogólnie tworzy się je takie jakie się chce i w zależności tego co chcemy osiągnąć.
2.Kto będzie tworzył moduły?
Pytanie dotyczy Falcona.
3.Czy Ty w jakimś "module,aplikacji?"przygotujesz dla nas zwykłych użytkowników coś podobnego?
Programiści tworzą moduły :) Oczywiście postaram się stworzyć tyle ile będzie potrzeba i mnie to nie przerośnie. Do Falcona, jak sam widziałeś jest już moduł, niedokończony ale jest :) Brakuje w nim kilkunastu zmiennych (m.in. tablicowych PFL, MFD, RWR). Tak więc moduł do Falcona będzie.
Czy można prosić o jakiś prosty przykład skryptu,aby wykonać testy.
Może dzisiaj uda mi się dodać kolejny wpis ze skryptem już działającym + udostępnię program w ostatniej wersji. Problem jest taki, że to testowanie to takie na "sucho" bo nie ma żadnych urządzeń oprogramowanych (co prawda zrobiłem wcześniej obsługę LCD - urządzenie + moduł - pokazywałem to w filmiku wiele wpisów temu, ale to czysta amatorka jeśli chodzi o sprzęt), Damos napisał niedawno, że za około 2 tygodnie będzie już można się za to zabrać :)
Testowanie na sucho jest o tyle dobre, że można się nauczyć tego "skryptowania" i zorientować jak to działa, no i wyłapać błędy :)
-
Testowanie na sucho jest o tyle dobre, że można się nauczyć tego "skryptowania" i zorientować jak to działa, no i wyłapać błędy
Dokładnie to miałem na myśli.
-
Kolejny wpis na stronie http://angus.foxnet.pl/fs/kokpit.html
-
Mały zwiastun tego, co się teraz u mnie tworzy...
http://www.fotosik.pl/pokaz_obrazek/510f0132f549823d.html
codeking,
Twoja szkoła jest bardzo pomocna :004:. Jak znajdę chwilę zrobię testy...
-
Brawo, EGHI, brawo. Niestety znalezienie surowego mdfu w moim mieście graniczy z cudem, ale się nie poddaję :)
Pozdrawiam
mickey81
-
mickey81,
to może tutaj poszukaj? http://www.allegro.pl/item679302472_plyta_mdf_10_mm.html
-
Trzymam się tego planu http://www.viperpits.org/smf/index.php?action=tpmod;dl=item12
Użyłem MDF 10mm. Straci to na szerokości jakieś 16 mm. Ale... mój tyłek się zmieści ;)
-
Jestem w dobrym położeniu dlatego,że w Poznaniu produkują te płyty.Wczoraj kupiłem jedną o wymiarze powyżej 2 m za 42 zł w zakładzie gdzie je produkują.Jest problem z transportem.
http://www.maltatrading.pl/go.live.php/PL-H16/produkty/P8557/mdf-surowe.html
Znalazłem także w Googlach innego producenta w Szczecinku,nie wiem czy można kupić w sklepie.
Odwiedziłem także sklep gdzie sprzedają monitory 10.4''
http://www.sempler.pl/index.php?cPath=1_4
Monitor jest drogi,kosztuje 959zł.Jest dotykowy,co w moim przypaduku (CP) jest zbędne.Dlatego propozycja EGHI wydaje się najbardziej optymalna z punku widzenia ceny.Odbiornik TV jest tańszy i może zastąpić monitor.Jest możliwość połączenia VGA z odbiornikiem TV za pomocą konwertera tak jak to zrobił EGHI.
Dzisiaj wykonam testy domowego kokpitu i opiszę moje wrażenia.
-
Sprawdziłem program domowy kokpit i mogę potwierdzić,że działa.Codeking mam do Ciebie prośbę,czy możesz zrobić zestawienie z pojęć,które już wprowadziłeś i które będziesz wprowadzał.Chodzi mi o takie pojęcia jak :słowa kluczowe,operatory itp.Są wprowadzone różne typy zmiennych,pojawiły się słowa kluczowe if,else operator + ,false,true itp.Tobie jako programiście będzie łatwiej to zebrać i zdefiniować.Ty to zrobiłeś,ale jest to umieszczone w różnych miejscach tekstu.Dobrze byłoby zrobić zestawienie tego co zostało już wprowadzone.Tyle moich sugestii.
-
Pisząc te wpisy miałem nadzieję, że będzie to swego rodzaju tutorial od zero do... i staram się po kolei lecieć od rzeczy najważniejszych i prostych do tych trudniejszych. Taki "sylabus" może być przydatny, postaram się go utworzyć.
-
Codeking chyba przesadziłem z tym zestawem.Można to zrobić pod koniec tutoral.Faktycznie wprowadzasz systematycznie zmienne oraz operatory i je definiujesz.Może koledzy także wyrażą swoją opinię.Dla mnie jest zrozumiały i trochę przypomina ten z OC.
EGHI gratulacje za wykonanie ACESII i dzięki za plan.Z planu wynika,że będę musiał kupić grubszy MDF 6 mm to trochę za mało.
-
Wykonałem kolejny model HudBox i połączyłem z CP.Są to tylko modele wykonane z tektury 2.5 mm.Będą podstawą dla prototypów wykonanych z MDF 6 mm.Najtrudniejszy do wykonania będzie ACESII,ale to dopiero po wakacjach
(http://img18.imageshack.us/img18/6721/dscn2398p.th.jpg) (http://img18.imageshack.us/i/dscn2398p.jpg/)
(http://img41.imageshack.us/img41/6769/dscn2399v.th.jpg) (http://img41.imageshack.us/i/dscn2399v.jpg/)
-
Dla EGHI i innych chcących budować gaugesy: http://www.mikesflightdeck.com/mfdbooks.htm
-
vito_zm, nie przestajesz mnie zadziwiać. Super! Wybadałem skąd można wziąć 6mm MDF. Taką płytą zabezpiecza się palety. Daje się jedną na spód i jedną na wierzch. W poniedziałek pędzę negocjować ceny :)
-
Mickey81 może to Ciebie zainteresuje,F16 w środowisku DSX
http://www.viperpits.org/smf/index.php?topic=5018.msg70777;topicseen#new
-
Widziałem, bardzo ciekawa konstrukcja, na pewno coś wykorzystam :)
-
siema ej mam pytanie jak mozna ustwaic na 1 monitorze np wysokosciomierz predkosciomierz sztuczna wysokosc a na drugim widok z okna?? (w MFS X)
-
na jednym monitorze ustawiasz widok kokpitu 3d, po czym wyłączasz tablicę przyrządów Shift+2. W drugim oknie możesz zostawić sobie VC. Niektóre domyślne modele np 737 mają możliwość oddokowania okien poszczególnych przyrządów. Kombinacje Shift+[cyfry od 1-0]
Powodzenia
mickey81
-
czyli takim sposobem uzyskam podobny efekt jak tutaj tak? http://butik.luftbrandzlung.org/kokpit/kokpit2_8.jpg
-
dokładnie tak. Ja tak latam na B737 i jest to bardzo wygodne.
Pozdrawiam
mickey81
-
przed kazdym lotem trzeba to ustawiac ? czy samo sie zapisze? bo obecnie nie moge sprawdzic...
-
przed każdym lotem, to jedyna niedogodność
-
Wystarcz zapisać lot (; albo menu pod latem), o ile pamiętam FS zapamiętuje położenie paneli.
-
tzn czy po kazdym wylaczeniu MFS trzeba bedzie ustawiac od poczatku?
-
Jeśli zgodnie z tym co piszesz nie możesz teraz sprawdzić, to poczekaj aż będziesz mógł i sprawdź a nie pytasz się 3 razy o to samo. Dwie osoby powyżej Ci odpowiedziały na to pytanie.
Tak w ogóle to zaczynaj zdania z wielkiej litery i używaj polskich znaków. Następny post napisany w ten sposób pójdzie do kosza.
-
sorki ze to sie tyle razy dodalo cos mi sie zwalilo jestem u babci i tu sie net pierdoli....
Some1 spokojnie ostrzegał, a ja dołożę :icon_luger_148: - za uporczywe łamanie zasad poprawnej pisowni i stosowanie wulgaryzmów!
Razorblade1967
-
Prace nad forumowym projektem ucichły - wiadomo - wakacje :) Ale osobiście coś dłubię w aplikacji i mam już moduł do obsługi wyświetlaczy LCD. Działa z wyświetlaczami podpinanymi pod RS232 ale moduł dla wyświetlaczy z projektu w tym wątku będzie praktycznie identyczny. Nagrałem dwa filmiki ale nie wiedziałem jak wstawić jeden obraz w drugi - nie wiem, nie znam się, zarobiony jestem - to są dwa oddzielne filmiki na YT:
Podgląd na aplikację:
http://www.youtube.com/watch?v=GqCTjsbKHxo (http://www.youtube.com/watch?v=GqCTjsbKHxo)
Podgląd na wyświetlacz:
http://www.youtube.com/watch?v=rBwnc9X80QQ (http://www.youtube.com/watch?v=rBwnc9X80QQ)
-
Moje gratulacje Codeking.Ja jestem tylko kibicem,ale sledze watek.Bede w Polsce pod koniec Sierpnia to wlacze się do tematu
pozdrawiam
-
Prace nad forumowym projektem ucichły - wiadomo - wakacje
To prawda,mysle jednak,ze programiści sa aktywni.Codeking czy wersja z RS231 może obsluzyc PFL z Falcona?
Co do mnie to działam zdalnie tzn.zamowilem LCD pod CP do Falcona.
LCD 3.3''
http://cgi.ebay.com/3-5inch-TFT-LCD-640x480-PVI-PD035VX2-Package-offer_W0QQitemZ300304828302QQcmdZView
LCD 10.4''
http://www.chinavasion.com/product_info.php/pName/104-inch-touchscreen-lcd-with-vg
Zamowilem z Chin,ponieważ u nas cena jest znacznie wyższa.Teraz czekam na przesylke okolo 2-3 tygodni.
PS
EGHI czy jest już mozliwosc przeslania do Ciebie maila na priv
Przepraszam za pisownie.
-
Codeking czy wersja z RS231 może obsluzyc PFL z Falcona?
Wyświetlić na pewno się da (może dzisiaj spróbuje), tylko trzeba wziąć pod uwagę fakt, że PFL ma chyba 5 wierszy po 25 znaków (tyle zwraca biblioteka do odczytu danych z Falcon'a). Posiadam wyświetlacz 4x20 więc trochę poucinam i ostatni wiersz odpadnie. Nie wiem czy można zdobyć wyświetlacze np. 5x25 na HD44780.
-
Dzięki za test.Zrobię rozeznanie w temacie.Nie mam dostępu do symulatora.Jak wroce do Polski to bede probowal rozwiazac problem.
-
Dzięki za test.
Filmik pokazujący co dzieje się na wyświetlaczu gdy klikam co popadnie :)
http://www.youtube.com/watch?v=Itykh6tro0o
-
Moje gratulacje Codeking,będzie o.k.
-
vito_zm - dobrym rozwiązaniem w tym przypadku byłby wyświetlacz graficzny, są większe i można wyświetlać dowolne znaki.
-
Tez o tym pomyslalem,jedyny problem to oprogramowanie,czyli prośba do programistów.DED mam na wyświetlaczu graficznym z klawiatury G15.PFL chce rozwiazac stosując nasz pomysł,jeśli to się uda.Niektórzy stosują LCD oraz FalconGauges,ale to już moim zdaniem przesada.
-
Niektórzy stosują LCD oraz FalconGauges,ale to już moim zdaniem przesada.
Dlaczego? Jeśli zbywa jakiś stary 15" LCDek, to według mnie to tańsze rozwiązanie niż kilka mniejszych wyświetlaczy. Chociaż przyznaję, że wyglądają super.
Pozdrawiam
mickey81
-
Nie wiem czy już było. Warto obejrzeć. http://www.youtube.com/watch?v=Akd4OdGHvNo
-
Prace nad forumowym projektem ucichły - wiadomo - wakacje :)
Kto ma wakacje, ten ma... inwestor z UK dodał kilka wymagań i mamy w firmie robotę 18 godzin dziennie 7 dni w tygodniu, do tego chrzest, wycięcie wyrostka itd...
Jednak postępy choć wolne, to jednak są :)
Męczę się teraz z mapowaniem abstrakcyjnego urządzenia virtualnego na fizyczne. Część stricte serwerowa już chodzi.
-
Kto ma wakacje, ten ma...
Masz racje,mam nadzieje,ze firma zrekompensuje Twoje zaangażowanie.Jeszcze 3 tygodnie i bede w kraju
pozdrawiam,vito_zm
-
Dobra wiadomość dla tych co budują MFD
http://www.viperpits.org/smf/index.php?topic=5076.15
2 sztuki kosztują 80 EUR.LCD trzeba dokupić.
Co do mojego projektu to kupiłem w Chinach przez eBay 2 LCD do mojego CP.Jeden jest sprawny z 3.5'' mam problemy.Jestem w kontakcie z sprzedawcą.Napiszę o tym więcej gdy rozwiążę problem.
-
Witam po dłuższej przerwie.
Bardzo atrakcyjna cena tego cacka co podał Vito. Biorąc pod uwagę stopień trudności i koszty wykonania w własnym zakresie to naprawdę niewiele. Chyba się skuszę.
Moja "choinka" powoli zaczyna świecić. Zacząłem od lewej strony, może do końca roku uda mi się wszystko zaświecić.
http://www.fotosik.pl/pokaz_obrazek/9616fa6e0e489110.html
http://www.fotosik.pl/pokaz_obrazek/8ba6003512c7c858.html
http://www.fotosik.pl/pokaz_obrazek/ba28e79928a5ac89.html
Pozdrawiam wszystkich.
-
Moje gratulacje EGHI,wygląda wspaniale.Życzę wytrwałości i powodzenia.
-
Witam ponownie,
zacząłem uzbrajać centralną konsole w panele i LCD.
http://img525.imageshack.us/i/p1020455r.jpg/
Mam mały dylemat i w związku z tym pytanie. Obok EHSI na panelu po lewej stronie jest pokrętło HGD z opcją Push. Zastanawiam się czy jest sens pakować tam encoder, czy zrobić atrapę?? Dodam że mój sim bazuje na wersji OF 4.5 a tam to nie działa.
Pozdrawiam.
-
Witam,
kolejna dobra wiadomość dla falconowców budujących kokpity dla F16.
Lightning zintegrował program FG z swoim MFD extractor
http://www.viperpits.org/smf/index.php?topic=5107.15
pozdrawiam
-
Kolejne wypociny,
http://img143.imageshack.us/i/p1060467.jpg/
Vito jesteśmy na podobnym etapie :001:. Chodzi mi o CP rzecz jasna.
-
Informacje na temat postępów prac w moim kokpicie zamieściłem tutaj http://f16pit.dbv.pl
Strona jest jeszcze w budowie, będzie uzupełniona ale zapraszam już teraz. Wszelkie sugestie co dodać, skasować, zmienić mile widziane.
Zapraszam.
-
Gratulacje,jak zwykle profesjonalnie zrobione.
-
Bardzo dobrze,że powstała strona EGHI.Można tam znaleźć więcej szczegółów.Są też projekty paneli z wymiarami.Mam nadzieję,że będzie uzupełniona opisem rozwiązań w dziedzinie elektroniki oraz oprogramowania.Prawdopodobnie część rozwiązań w dziedzinie elektroniki będzie podobna do moich rozwiązań to chętnie ją uzupełnię.
Mam nadzieje,że nasze polskie rozwiązanie hardware oraz soft też zostanie zrealizowany.Korzystam narazie z opracowań OC ze względu na założony termin realizacji swojego kokpitu.Jednocześnie deklaruję pełną współpracę przy tworzeniu naszej platformy.Zdaję sobie sprawę,że jest to proces długotrwały i należy uzbroić się w cierpliwość.
Na zakończenie taka reflekcja.Pojawienie się 2 lata temu Intrudera na naszym forum było dla mnie impulsem do kontynuacji budowy kokpitu.
Obecnie pojawienie się EGHI na forum dało dalszy impuls do realizacji budowy kokpitu F16.Jednocześnie EGHI narzucił takie tempo,że nawet ja mam problemy aby nadążyć.Jest to bardzo optymistyczne,ponieważ jest nadzieja,że pojawią się kontynuatorzy.
-
Ponieważ widzę, że cisza że aż .... zapraszam do odwiedzenia mojej stronki www.a320-project.skalarki.co.uk (http://www.a320-project.skalarki.co.uk), na której umieściłem kilka najnowszych informacji o postępach prac nad moją wersją elektroniki, o której pisałem już parę miesięcy temu. Dopiero teraz miałem możliwość odpalenia tego wszystkiego i jestem bardzo zadowolony z efektów. Całość znacznie różni się od planów Damosa ale mimo wszystko chyba jest prostsze w budowie ... Ale oceńcie sami.
Ponieważ kilku kolegów pyta o możliwość podpięcia tego do FALCONA - odpowiadam - nie ma problemu - trzeba tylko kogoś kto zrobi soft żeby się to wszystko mogło dogadać. Stawiam na codeking-a, ale czy zechce?
-
Bardzo funkcjonalny oraz uniwersalny projekt.Podział na 3 mniejsze moduły ma sens,przekonałem się o tym w praktyce.Ilość wejść oraz wyjść przy możliwości budowania modułów wystarczająca.Zapytam na pw o szczegóły.
Stawiam na codeking-a, ale czy zechce? Ja też stawiam na codeking.Mogę wykonać prosty prototyp i go testować pod kątem falcona.Dla mnie jest ważny oprócz hardware soft a konkretnie sposób pisania skryptów (stopień trudności) oraz możliwość testu.Kończę opis swojej elektroniki w moim kokpicie na stronie AGHI http://f16pit.dbv.pl i w trakcie pisania tego wątku widzę jak ważny jest soft oraz testowanie.Jeszcze raz deklaruję pomoc w testach,ale potrzebuję soft codeking.
Projekt Damosa jest bardziej uniwersalny i bardzo dobrze,że jest szansa aby stworzyć polskie platformy dla symulatorów.Życzę obu panom Skalarki oraz Damosowi sukcesów w ich projektach jednocześnie deklaruję pomoc,niestety tylko jako "hardwarowiec"
pozdrawiam i życzę sukcesów
vito_zm
-
Stawiam na codeking-a, ale czy zechce? Ja też stawiam na codeking.Mogę wykonać prosty prototyp i go testować pod kątem falcona.
...
Jeszcze raz deklaruję pomoc w testach,ale potrzebuję soft codeking.
vito_zm
Ok, potrzebuje "interfejsu" od skalarki i można kodować.
Skalarki - jaki jest orientacyjny koszt wykonania tej platformy i czy trzeba od razu lutować całość czy można uruchomić np. tylko wyświetlacze LED ?
-
Ok, potrzebuje "interfejsu" od skalarki i można kodować.
Odpiszę na PW w sprawie interfejsu.
Skalarki - jaki jest orientacyjny koszt wykonania tej platformy i czy trzeba od razu lutować całość czy można uruchomić np. tylko wyświetlacze LED ?
Prezentowana płytka zawiera:
1xPIC18f4550
7xMCP23S17
3xMAX7221
+ kilka drobnych elementów
Ja kupowałem wszystko z różnych źródeł ale wg cen TME to będzie około: 150zł + płytka więc w sumie trochę więcej niż sama płytka expansion od OC. Płytka prtotypowa kosztowała 160zł :008: ale przy większym zamówieniu może być taniej.
Nie trzeba lutować wszystkiego. Wymagany jest tylko PIC + parę małych elementów. Każdy element wykonawczy jest niezależny i można je dolutowywać później. Czyli można uruchomić na początek wyświetlacze ( nie koniecznie 24 na raz) i będzie ok.
-
Brawo Skalarki, very very bravo :001:
Ok, potrzebuje "interfejsu" od skalarki i można kodować.
Skalarki - jaki jest orientacyjny koszt wykonania tej platformy i czy trzeba od razu lutować całość czy można uruchomić np. tylko wyświetlacze LED ?
Czy ta deklaracja jest możliwa do realizacji?
Chętnie pomogę....nie jestem informatykiem, nie jestem elektronikiem ( mam znikome podstawy)
nie dołożę w tych dziedzinach nic od siebie, ale mogę wesprzeć testy finansowo. Jeśli tylko jest szansa odpalić to w Falconie. :001:
-
Dla mnie jest ważny oprócz hardware soft a konkretnie sposób pisania skryptów (stopień trudności) oraz możliwość testu
Ja w swoim projekcie mam do tego całkiem inne podejście. Wogóle nie przewiduję możliwości umieszczania własnych skryptów bo i po co. Wszystko będzie gotowe i użytkownik nie będzie musiał się niczym przejmować. Obecnie dopasowuję kod do WILCO AIRBUS a potem zrobi się kopię softu do dowolnie innego ARBUZA w zależności co się pojawi narynku. Takie podejście znakomicie ułatwia pracę dla programisty softu bo czyni projekt o wiele łatwiejszym. Myślę że codeking się zgodzi.
-
Myślę że codeking się zgodzi.
Z punktu widzenia programisty - TAK, z punktu widzenia użytkownika konkretnego produktu (wspominasz o Wilco) - TAK, z punktu widzenia użytkownika latającego na różnych maszynach i symulatorach - wiadomo :)
Sam też przez jakiś czas miałem rozwiązanie "kodowe" czyli program nakierunkowany na konkretną obsługę ale ze zmianami do innych maszyn itp. był problem. Ale jeśli skalarki robisz produkt "gotowiec" to ma sens i masz większe możliwości dostosowania komunikacji sprzęt<->oprogramowanie<->symulator.
-
Dyskusja zrobiła się ciekawa.Próbuję jako laik w sofcie zrozumieć idee skalarki mam na myśli Falcona.Jeśli założymy,że w pamięci współdzielonej mamy informację o parametrach symulatora Falcon pod odpowiednimi adresami to ta informacja musi być przekazana interfejsem programowym do programu skalarki (odpowiednik FAST oraz SIOC).Po stwierdzeniu,że jest zmiana zmiennej w share memory program wystawia na odpowiedni port sygnał typu zapal,zgaś (LED) lub wartość do wyświetlenia (7-seg.LED).Wynika z tego wniosek,że zmienne symulatora Falcon są na sztywno przyporządkowane do fizycznych portów platformy.Tak to widzę,jeśli się mylę proszę o korekcję.
Z punktu widzenia użytkownika symulatora Falcon jest to wygodne,nie wiem jak to wygląda z punktu widzenia programisty.
Co do wejść to prawdopodobnie nie ma sztywnego przyporządkowania,tak myślę.Jeśli jestem w błędzie proszę o wyjaśnienie.
-
Jeśli Shared Memory działa podobnie jak biblioteki FSUIPC, to bez problemu Skalarki dostosuje to swojego softu. Podejrzewam jednak, że tak nie jest.
-
Próbuję jako laik w sofcie zrozumieć idee skalarki mam na myśli Falcona.Jeśli założymy,że w pamięci współdzielonej mamy informację o parametrach symulatora Falcon pod odpowiednimi adresami to ta informacja musi być przekazana interfejsem programowym do programu skalarki (odpowiednik FAST oraz SIOC).
Do działania moich modułów I/O nie jest wcale potrzebny mój soft, który zresztą pisany jest tylko dla Airbusa. Całe sterowanie opiera się na wysyłaniu i odbieraniu odpowiednich informacji do i z USB. Ja dostarczę coś na kształt biblioteki funkcji np kodeking-owi czyli zapis do wyświetlacza, zapis do LED-a oraz odczyt wejść i enkoderów i tyle. On te funkcje tylko będzie musiał wywoływać w odpowienidm momencie np. po tym jak zmieni się informacja w shared memory (nie znam tego dokłądnie to nie wiem na razie jak to działa). Czyli z shared memeory codeking będzie bezpośrednio czytał informacje i wysyłał do moich I/O i na odwrót. Odczyt z moich I/O i zapis do shared memory. Ja robię dokładnie to samo tylko wykorzystuję Simconnect albo FSIUPC.
Co do wejść to prawdopodobnie nie ma sztywnego przyporządkowania,tak myślę.Jeśli jestem w błędzie proszę o wyjaśnienie.
To zależy tylko od tego jak codeking to zrobi. Ja robię sztywne przyporządkowanie dla Airbusa - nie chcę mieć setek maili z prośbami o pomoc w konfiguracji bo coś nie działa. Nie ma jednak żadnego problemu żeby to zrobić na różne sposoby.
-
Odczyt z moich I/O i zapis do shared memory
Jedna uwaga.Falcon różni się od FSX tym,że nie można modyfikować share memory tzn.nie przyjmuje danych.Dane można jedynie odczytywać z pamięci i je wstawiać na porty.Dane na wejściu można tylko traktować jako emulację klawiatury,podobnie jak w SVMapper (MJoy).
Myślę,że codeking może wyjaśnić jak widzi mechanizm współpracy platformy skalarki z share memory.Nareszcie odżył zapomniany wątek.
-
Z mojej strony to nie ma znaczenia czy to shared memory czy wywoływanie odpowiednich funkcji, bo w mojej aplikacji i tak wszystko jest tak "tłumaczone" aby w skrypcie widoczne były zmienne na których można pracować prostym skryptem.
Tak przy okazji to wkrótce (na dniach) udostępnię nową wersję z modułem dla FS'a i pokażę jak zrobić proste radio, narazie oczywiście bez wyświetlaczy.
Skalarki - udostępnisz schemat tak, żeby chętni mogli polutować, no i czy płytkę można kupić już gotową (czy firma która ją wytrawiała ma już kliszę i może zrobić serię kilku/nastu płytek) ?
Edit: Z Falconem jest tak jak pisał vito_zm, nie ma zapisywania do SharedMemory dla Falcon'a (chociaż jest tak naprawdę jeden czy dwa offsety w FAST do którego można coś zapisać). Tak więc sterowanie tylko mysz, klawiatura lub joystick.
-
mojej aplikacji i tak wszystko jest tak "tłumaczone" aby w skrypcie widoczne były zmienne na których można pracować prostym skryptem
To sugeruje,że Twoje rozwiązanie jest w jakimś sensie podobne do rozwiązania Michi w jego FAST.On wprowadził zmienne,które są skorelowane z Falconem,są widziane przez SIOC i można nimi operować pisząc skrypt.Jednocześnie można w prosty sposób przypisać im fizyczny port w platformie.
Wracając do idei skalarki jeśli dobrze zrozumiałem to można dla konkretnej maszyny mając dostęp do jej danych wystawiać określone alarmy na określone fizyczne porty.
Podobnie z danymi do wyświetlenia na 7-seg.LED.W przypadku takiego rozwiązania użytkownik musiałby połączyć odpowiednie porty z odpowiednimi wyświetlaczami bez potrzeby pisania skryptów.Programista znając daną maszynę (symulator) napisałby odpowiedni program i na tym koniec.Czy dobrze zrozumiałem?
-
Proponuje dać zającowi płytkę do zaprojektowania on wie jak stworzyć cacko z każdego projektu :) nie mogę się doczekać jakiś konkretnych danych tego układu (buduje 747-400). Pytanie jeszcze z innej beczki ...
skalarki:
Widziałem na twojej stronie TQ cięte laserem czy to ty masz takie możliwości cięcia czy komuś dajesz do zrobienia? no i ostatnie pytanie czy te zębatki masz robione w taki sam sposób czy masz gdzieś dostęp do tanich gotowych.
-
Tak przy okazji to wkrótce (na dniach) udostępnię nową wersję z modułem dla FS'a i pokażę jak zrobić proste radio, narazie oczywiście bez wyświetlaczy.
Akurat szkoda bo mi na wyświetlaczach właśnie najbardziej zależy.
ps przepraszam ale nie mogłem już wyedytować poprzedniego posta.
-
Akurat szkoda bo mi na wyświetlaczach właśnie najbardziej zależy.
Na wyświetlacze musimy poczekać na zakończenie forumowego projektu lub urządzenia skalarki.
PS. Podoba mi się Twoje TQ. Trzeba pomyśleć o podobnym...
-
Proponuje dać zającowi płytkę do zaprojektowania on wie jak stworzyć cacko z każdego
Nie trzeba nic projektować. Skalarki ma już gotowe płytki i właśnie je montuje.
Jak wspomniał codeking, trzeba poczekać aż jego program "Domowy kokpit" będzie współpracować z sprzętem Skalarki.
-
Nie trzeba nic projektować. Skalarki ma już gotowe płytki i właśnie je montuje.
Dokładnie płytki wyglądają wspaniale - moje gratulacje.
Mam pytanie dotyczące samego projektu skalarki - w jaki sposób będą programowane układy i czy będzie taka konieczność. Co do programu do ich obsługi to może wykorzystać / przynajmniej do Flight Simulatora / współprace z FSUIPC - wtedy każdy mógłby dopasować sobie obsługę tego projektu do każdego samolotu jaki jest w FS-e
I jeszcze jedno - jaka będzie możliwość podłączenia większej ilości wyświetlaczy 7-segmentowych - do mini kokpitu 737NG bardzo dużo wychodzi, czy będzie to osobna płytka podpinana do głównej ??
Na razie latam na takiej konstrukcji
(http://img40.imageshack.us/img40/8440/img1813p.th.jpg) (http://img40.imageshack.us/i/img1813p.jpg/) (http://img42.imageshack.us/img42/6345/img1810k.th.jpg) (http://img42.imageshack.us/i/img1810k.jpg/) (http://img690.imageshack.us/img690/6446/img1812n.th.jpg) (http://img690.imageshack.us/i/img1812n.jpg/)
Właśnie przymierzałem się do jakiegoś pedestala / tam gdzie stołek na pierwszym zdjęciu /, ale chyba poczekam na projekt skalarki, chciałbym mieć wyświetlacze, przy radiu się przydaje
pozdrawiam i życzę powodzenia - Zając
-
I jeszcze jedno - jaka będzie możliwość podłączenia większej ilości wyświetlaczy 7-segmentowych - do mini kokpitu 737NG bardzo dużo wychodzi, czy będzie to osobna płytka podpinana do głównej ??
Na jednej płycie (głównej) możesz mieć 32 wyświetlacze, 128 wyjść, 128 wejść. To wszystko można poszerzać o kolejne 128 wejść.
Tyle wiem :) , więcej Skalarki wyjaśni.
-
Prezentowana płytka zawiera:
...
3xMAX7221
...
Z tego wynika, że 3x8cyfr 7-seg (MAX7221 pozwala na podłączenie 8x7seg)=24 cyfry 7seg
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1339 (http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1339)
miłej lektury i czekam na info od kolegi skalarki nt cięcia laserem.
-
Nieskromnie zapraszam na stronę http://fs.angus.foxnet.pl/ Wrzuciłem nową wersję aplikacji DomowyKokpit, moduł dla FS i skrypt realizujący multiradio.
-
Moje gratulacje codeking.Przejrzałem pobierznie Twoją strone,jest interesująca,ale wymaga czasu aby wejść w szczegóły.Korzystając z okazji mam pytanie ogólne dotyczące 2 projektów skalarki oraz Damosa oraz Twojego udziału w realizacji aplikacji do FSX oraz Falcona.
1.Czy oba projekty wymagają napisania skryptu do realizacji sterowania kokpitu.
2.Jeśli tak to czy jest duża różnica w pisaniu skryptu do FSX oraz Falcona.
Pytam dlatego,że w projekcie skalarki była mowa o programie na poziomie projektu do konkretnej maszyny.Zadałem to pytanie wcześniej,ale nie otrzymałem odpowiedzi
pozdrawiam,vito_zm
-
Nie chcę pisać aplikacji osobnych dla różnych symulatorów, dlatego ukierunkowałem się na skrypty - rozwiązanie ogólne i bez wiązania się z którymś z symulatorów na stałe. Różnica pomiędzy pisaniem skryptów dla FSX i Falcon'a to taka, że korzysta się z innych zmiennych i funkcji, ale cała idea pozostaje ta sama. Jeśli powstanie moduł do obsługi projektu skalarki to będzie on udostępniał odpowiednie zmienne i ew. funkcje jak każdy inny moduł, to samo tyczy się projektu Damosa i innych, jeśli takowe powstaną i będzie udostępniony interfejs programistyczny aby z nich skorzystać.
Zdaję sobie sprawę z tego, że aplikacja (DomowyKokpit) na chwilę obecną nie jest nikomu do niczego potrzebna - bo i po co ? Wyświetlanie stosu radia w okienku, sterowanie klikaniem myszki - nie o to chodzi w budowaniu paneli. To czy aplikacja będzie spełniać swoje zadanie i bez problemu będzie można z niej korzystać okaże się dopiero gdy będą dostępne urządzenia, które da się wykorzystać (LCD, LED itd., nie liczę kontrolerów gier bo ich obsługa wkrótce będzie dostępna). Tak więc pozostaje cierpliwość, osobiście trochę mi jej brakuje przy tym projekcie, nie ma "choinki" nie ma zabawy.
-
Takie macanie cukierka przez papierek ... mamy papierek ale nie ma cukierka, o lizaniu cukierka nie wspominając :)
-
Dobrze napisane ;)
-
Nie wiem jaki jest stan projektu Damosa ale ja obecnie jestem na etapie testowania już gotowej płytki prototypowej, jak widać na filmiku na mojej stronie. Jak to zawsze z prototypami musiałem zrobić kilka drobnych poprawek w projekcie płyki ale tylko kosmetycznych. Ale jeśli jest ktoś chętny to będę wkrótce zamawiał kilka zestawów płytek dla klientów ze świata. Im więcej chętnych tym lepiej będzie taniej.
To czy aplikacja będzie spełniać swoje zadanie i bez problemu będzie można z niej korzystać okaże się dopiero gdy będą dostępne urządzenia, które da się wykorzystać (LCD, LED itd., nie liczę kontrolerów gier bo ich obsługa wkrótce będzie dostępna). Tak więc pozostaje cierpliwość, osobiście trochę mi jej brakuje przy tym projekcie, nie ma "choinki" nie ma zabawy.
Kodeking lub i Vito_zm: jeśli chcecie mogę odsprzedać jedną z płytek prototypowych, które mam obecnie w domu. Może to być sama płytka po cenie jaką zapłaciłem, płytka + elementy (zaprogramowany PIC) jako kit do montażu albo gotowa zlutowana i uruchomiona płytka.
Będzie można wtedy testować na żywo swoje oprogramowanie no i moglibyśmy współpracować nad dopracowaniem oprogramowania PIC-a
Dostępne płytki:
1. 63 wejścia + 48 wyjść + 24 wyświetlacze 7-seg + 4 gniazdka rozrzerzające - 1 szt.
2. 128 wejść + 128 wyjść + 32 wyświetlacze + 6 gniazdek rozszerzających - 2 szt.
-
32 wyświetlacze ... jaka cena za płytkę?
-
Ale jeśli jest ktoś chętny to będę wkrótce zamawiał kilka zestawów płytek dla klientów ze świata. Im więcej chętnych tym lepiej będzie taniej.
Ja się na to piszę.Co do prototypów to myślę,że na tym etapie projektu mam na myśli aplikacje do symulatorów taki prototyp jest niezbędny dla codeking.Co do mnie to jestem zależny od jego programu (mam na myśli aplikację do Falcona).
-
Ktoś musi testować działanie pod fsx z PMDG 747-400X i Precision Simulator 1.3 B744 (747-400)
-
skalarki - jakieś szacunkowe koszty tych płytek już znasz? Możesz rzucić jakąś kwotę?
Jest ktoś zainteresowany wykorzystać to w simach serii FS9/FSX ?
-
No przecie ja jestem od FSX :)
-
Ja się na to piszę.Co do prototypów to myślę,że na tym etapie projektu mam na myśli aplikacje do symulatorów taki prototyp jest niezbędny dla codeking.Co do mnie to jestem zależny od jego programu (mam na myśli aplikację do Falcona).
Płytki zostały sprzedane. Jedna jedzie do codekinga a druga d EGHI. Więc trzeba teraz poczekać aż przesyłka dotrze no i na komentarze od obu panów.
skalarki - jakieś szacunkowe koszty tych płytek już znasz? Możesz rzucić jakąś kwotę?
Jeśli chodzi o koszty to poczekam aż codeking dostanie płytkę i powymieniamy opinie. Być może będzie konieczna modyfikacjia projektu aby ułatwić korzystanie z niego przez Falconowców (trzeba pamiętać że projekt od początku był nakierowany tylko na Airbusa).
Jest ktoś zainteresowany wykorzystać to w simach serii FS9/FSX ?
Na tym forum to chyba nie za bardzo ale ja mam już kilku chętnych ze świata. No i ja sam robię soft pod kątem FSX-a. Jak się projekt codekinga rozpędzi to według jego filozofii, jego softem będzie można sterować każdym simem, na tyle na ile to oczywiście możliwe.
-
Szkoda ... bo chciałem potestować. Projekt Damosa też ciekawy ale gdzieś przystanął w pół drogi.
-
Seeb,
niewiele byś z tym zrobił bez odpowiedniego softu, a tym zajmie się codeking. Dopiero po zgraniu aplikacji nad którą pracuje będzie można testować. Na dzień dzisiejszy tylko Airbus Skalarki działa z projektem.
-
ech myślę ze codę by się podzielił efektami swojej pracy ... a i o ukrywanie source na razie też go podejrzewać nie będę :)
tak na marginesie to powoli przypominam sobie jak się programowało w c++ więc może kiedyś byłbym przydatny
-
Przecież dzieli się cały czas, na tej stronie http://angus.foxnet.pl/fs/blog/ :001:
-
rzuciłem tam tylko okiem dlatego napisałem, że nie będę go posądzał o ukrywanie kodu zatem płytka była by przydatna :)
-
Szkoda ... bo chciałem potestować.
Napisz, która płytka by cię interesowała to zamówię więcej kolejnym razem.
-
podaj jeszcze cenę przy okazji ...
mówiłem o tej z dużą liczbą wyświetlaczy (32) bo zasadniczo teraz to wyświetlacze mi są potrzebne ... no i jeśli wolno spytać jakie są jej wymiary ... nie ukrywam, że fajnie by było odpalić MCP i nieszczęśliwe radio.
Tak troszkę off-topic latałeś na WF2008?
-
Damos działa z tego co wiem to jego projekt będzie gotowy być może jeszcze w tym roku.Bardzo dobrze się stało,że jeden prototyp trafił do codeking a drugi do EGHI.Codeking tworzy aplikację zarówno do FSX jak i do Falcona a EGHI jest w trakcie realizacji projektu Falcona.Gdy będzie już aplikacja do Falcona to chętnie pomogę w testach.
-
Jest jeszcze Precision Simulator B744 v1.3 (747-400), który też pewnie dobrze by oprogramować. Wyjątkowo bo po wyczerpaniu nakładu CD otrzymałem w prezencie kopię z dystrybucji online. Pewnie dlatego, że w 2010 roku pojawi się zupełnie nowa wersja (sądzę, że chodzi o wersję całkowicie windowsową). Dla niewtajemniczonych Precision Simulator to główny powód istnienia precision mauals, z którego powstało Precision Manuals Development Group w skrócie PMDG.
-
skalarki zapomniałem zapytać
Przewidziałeś zapalanie pojedynczych lampek (np na MCP LNAV,VNAV, V/S, HOLD(ALT,HDG), SPD, THR,FL CH,LOC, APP, CMD(L,C,R)) itd. ?
-
Wyjścia są do sterowania pojedynczych LED.Jeśli przewidujesz zastosowanie lampek zamiast LED to można samemu wykonać prosty interface podający wyższe napięcie np.24V.
-
Nie planuję ... nawet w domu mam oświetlenie świetlówkowe i LED (Gwint E14) energooszczędność jeszcze nie dotarła do mojego komputera... chociaż monitor bierze 60W a nie jak poprzedni 110W za to zasilacz ma 2x550W
-
Ponieważ widzę, że jest sporo niejasności dotyczących mojego projektu jak również tego co robi codeking, napiszę trochę aby rozjaśnić niewtajemniczonych co i po co i jak.
Aby sterować przełącznikami samolotu czy to w FSX, FS9 czy FALCON potrzebne jest urządzenie peryferyjne (w moim przypadku podłączona przez USB płytka I/O). Płytka ta (a raczej mikrokontroler) ma wgrane oprogramowanie, które odpowiada za dogadanie się z komputerem a konkretnie oprogramowaniem (np. w przypadku codekinga "Domowy kokpit"), a w moim przypadku I/O SKALARKI SOFTWARE, które to zaś jest pomostem z np. FSX, FS9 czy FALCON. Ale po drodze aby dostać się do FS9 trzeba skorzystać z FSUIPC Petera Dowsona. Program ten pozwala na odczyt i zapis danych do symulatora i działa jak kolejne ogniwo w całym łańcuszku. W przypadku FSX można skorzystać z FSUIPC ale lepiej wykorzystać Simconnect, specjalnie do tego stworzony interfejs programistyczny. Ja wykorzystuję obydwie biblioteki co daje większe możliwości.
W tym miejscu zaznaczyć trzeba że w przypadku FSX, czy FS9 można tak zmodyfikować program, że będzie możliwe sterowanie dowolnym, samolotem. Oczywiście na tyle na ile dany samolot pozwala symulować konkretny przełącznik itp.
Konkretnie moje oprogramowanie obsługuje defaultowego A321 oraz Wilco A320. Jeśli pojawi się jakiś nowy lepszy Airbus, również do niego będzie dostępna obsługa.
Teraz jak to się dzieje, że na podłączonym wyświetlaczu pokazuje się np HDG?
W moim przypadku oprogramowanie monitoruje non stop parametry samolotu w tym między innymi HDG. Jeśli zostanie odebrana z symulatora (FSX) zmiana wartości program wysyła informację do USB i dalej do mikrokontrolera płytki, ten zaś wysyła informację do układów sterujących wyświetlaczami.
Analogicznie jest w przypadku zapalania LED-ów.
Inaczej jest w przypadku przycisków i enkoderów. Oprogramowanie mikrokontrolera non stop sprawdza, czy na jakimś wejściu zmienił się stan np przycisk Autopilota został wciśnięty. Jeśli wykryje taką zmianę wysyła informację w formie pakietu do USB i dalej do progamu. Program analizuje odebrany pakiet i na tej podstawie wysyła informację do symulatora nakazującą włączenie Autopilota.
No i na koniec różnica pomiędzy moją koncepcją oraz koncepcją codekinga na oprogramowanie.
Otóż I/O SKALARKI SOFTWARE nie będzie dawał użytkownikowi możliwości konfigurowania poszczególnych wejść, wyjść itp. Wszystko będzie gotowe tak aby po podłączeniu potrzebnych przycisków, LED-ów, encoderów oraz odpaleniu konkretnego samolotu wszystko działało bez potrzeby jakiejkolwiej konfiguracji. Podejście proste ale ograniczone dla konkretnego modelu samolotu co zresztą było moim celem od początku.
Codeking natomiast tworzy aplikację niezależną od używanego samolotu czy nawet symulatora. Będzie można więc używając skryptów dostosować aplikację do własnych potrzeb.
Mam nadzieję, żę trochę rozjaśniłm, jeśli nie to pytać dalej. :002:
-
podaj jeszcze cenę przy okazji ...
mówiłem o tej z dużą liczbą wyświetlaczy (32) bo zasadniczo teraz to wyświetlacze mi są potrzebne ... no i jeśli wolno spytać jakie są jej wymiary ... nie ukrywam, że fajnie by było odpalić MCP i nieszczęśliwe radio.
Tak troszkę off-topic latałeś na WF2008?
Płytka co ma 32 wyświetlacze ma również 128 wejść i 128 wyjść no i możliwości rozszerzania. Jeśli potrzebujesz tylko wyświetlacze to nie jest dla ciebie rozwiązanie. Za drogo by cie kosztowało. Ale kolejna wersja płytek będzie trochę inna to wtedy będzie dla ciebie idealna do zrobienia MCP i radia. Obecne wymiary tej płytki to 25x17cm.
I nie wiem co to WF2008. :015:
skalarki zapomniałem zapytać
Przewidziałeś zapalanie pojedynczych lampek (np na MCP LNAV,VNAV, V/S, HOLD(ALT,HDG), SPD, THR,FL CH,LOC, APP, CMD(L,C,R)) itd. ?
Przewidziałem wszystko. Moja płytka I/O GLARE steruje całym FCU czy tam MCP + MIP.
-
Jeśli chodzi o mnie to akurat nie zmieniło nic nic nie zaciemniło a i nic nie rozjaśniło. Ale milo, że napisałeś... Ja pytałem tylko czy po za układami stricte zaprojektowanymi do 7-seg nie zapomniałeś o pojedynczych światełkach, które w kokpicie powinny być tu i ówdzie w szczególności ówdzie :)
Co do nowego posta:
Szczerze mówiąc miałem nadzieję na budowę czegoś modyfikowalnego... rozłączalnego itd etc..
Jeśli uda mi się odpalić to jakoś sensownie (mowie o precision simulator w zestawie widefs/fsuipc, FSX[obecnie mam FSX+PMDG 747-400X+FSUIPC+WIDEFS(wszystko legalne)]) to będę potrzebował naprawdę dużej ilości rzeczy ... w tym dużo wyświetlaczy lampek, podświetlenia włącznie, calej masy przycisków no i cały CDU który pewnie w odpowiednim kolorze zamówię u Ciebie :) Obecnie moje PMDG nie pozwala na EFIS i CDU własnej roboty (innego niż wybrańcy - producenta) a najtańszy CDU kosztuje ponad 1000$ + 90 Euro za sterownik co daje ponad 3300$ za same CDU + EFIS x2 to wydatek kolejnych 800 Euro(po 300 za sztukę + sterowniki).
Właśnie jestem w trakcie uruchamiania nieśmiało, właśnie Precision Simulator 1.3 na drugim komputerze (http://www.aerowinx.com)- dostałem w prezencie jako freeware.
THIS IS COPYRIGHTED MATERIAL -- PLEASE DO NOT DISTRIBUTE FURTHER
================================================================
The two other files in this directory contain the Full Pack release of the
Aerowinx 747-400 Precision Simulator version 1.3, and the associated manual.
Both files are copyright (C) 1995-2000 Hardy Heinlin and have been licensed
to you for personal use only, according to the normal rules and rights that
apply to the original release on CD-ROM and dead trees.
Since the simulator has sold out from all shops worldwide, the system is now
available free of charge to you, but it is not in any way released to the
world. You received a specific license from Hardy Heinlin to download and
use these files, but you are requested not to further distribute them, or
disclose the source URL.
WF to impreza wirtualnego latania - coroczna (http://www.worldflightgroup.com/).Myślę, o starcie całościowo w tej imprezie za rok.
Oczywiście w mojej wypowiedzi pojawił się błąd bo nie WF2008 a WF2009 :)
-
Może cie to też zainteresuje.
http://www.projectopensky.com/downloads-index.php
-
Seeb,
Nie chcę Cie dołować ale chyba nie uda Ci się dużo wydobyć z PMDG, a zwłaszcza lampki. PMDG nie udostępnia SDK. Chyba że masz listę Offsetów to OK. Lepszym rozwiązaniem jest soft od PM http://www.projectmagenta.com/ jest to kosztowne ale najlepsze i daje wielkie możliwości w porównaniu z PMDG.
Nie wiem jak to rozwiązał Skalarki w Wilco, ale na pewno wszystko nie zadziała. Ja sam męczę się z pewnym samolotem i już wiem, że poza tym co daje FSX nie wycisnę wiele.
Dopisze: Projectopensky+ProjectMagenta=cockpit ;)
-
PM jest naprawdę strasznie drogie ... tak prześledziłem parę forum o 747 i większość buduje PS1 + wyświetlanie scenerii z FS (od 98 do FSX włącznie) żeby było śmieszniej to PS1 udostępnia całą listę lampek, wyświetlaczy, etc. Jak wspomniałem model lotu PMDG pochodzi z PS1 (po małej awanturze wewnątrz teamu) przy czym PS1 jako program DOSowy nie miał możliwości się upiękrzyć za to poszedł w idealne odwzorowanie lotu i przyrządów... checklisty przypominają długością fabryczne B744 niż te 6wierszowe listy PMDG zatem jeśli faktycznie uda mi się po FSUIPC i WIDEFS podłączyć widoki scenerii z FSX to będę bardzo szczęśliwym posiadaczem softu zdolnego pomoc mi w budowie taniego(bądź też nie - zależnie od zasobów w kieszeni) symulatora. Powiem więcej PROC i GRAFA zajmą się tylko i wyłącznie pokazywaniem grafiki scenerii (wszystko zatem na max-maxów). A przykładem tego co można z tej pary wycisnąć niech będzie kokpit Matt'a: http://aerowinx.com/forum/topic.php?id=173 (http://aerowinx.com/forum/topic.php?id=173)
-
http://www.hoppie.nl/fdr/ o czymś takim w PM czy PMDG można tylko pomarzyć
-
Seeb z tego co piszesz wynika,że masz ambitne plany.Nie mogę się wypowiadać na temat FXS ponieważ nie znam tego symulatora.Zauważyłem także,że masz dużo wiedzy na temat oprogramowania wspierającego symulator FSX,ale gorzej z tzw.hardware,które niestety także występuje w kokpitach.W Twoim przypadku musisz się dobrze zastanowić jaką wybrać platformę.Możesz zastosować w projekcie kilka niezależnych platform jeśli zabraknie np.wyjść do sterowania LED ("lampek") lub 7-seg.LED.
Skalarki precyzyjnie opisał swój projekt oraz plany na przyszłość.Jeśli chcesz wykorzystać platformę dla innego samolotu musisz mieć dodatkowe oprogramowanie np.skrypt codeking.
Jeśli interesują Ciebie głównie 7-seg.LED to masz już gotowe rozwiązania OpenCockpits,gdzie do jednej płyty Master można podłączyć 4 karty Display co daje 64 7seg-LED.Jednocześnie Master steruje 45 LED ("lampkami").Płyt Master można podłączyć kilka do PC.Karty są sterowane programem SIOC z wykorzystaniem FSUIPC Petera Dowsona.
Ja przewiduję zastosowanie kilku projektów tzn.OC(który u mnie już działa),projektu skalarki i Damosa.Z wymienionymi na końcu projektami problem polega na tym,że trzeba napisać dodatkowe oprogramowanie w wspomnianym przez skalarki łańcuszku.
Reasumując możesz eksperymentować z OC jednocześnie cierpliwie czekać na soft codeking.
-
Tak naprawdę im bardziej wnikam w symulatory jako takie tym bardziej jestem przerażony ich brakami. Precision Simulator jest genialny jesli idzie o model lotu, programowalność paneli w realu możliwość pobierania danych o położeniu samolotu w osiach x,y,z nachyleniu etc (przydatne np przy budowaniu "motion platform") ale latanie na gołym jest wręcz niemożliwe. Zobacz jak to wygląda graficznie (http://aerowinx.com/assets/pics/ps13_appctr01.gif) (to okienko po lewej na górze to jest widok przez okno - jak znajdę jakiś odpowiednik z FS'a to zamieszczę) w sumie bez drugiego kompa się nie obejdzie ... zważywszy, że kupiłem FSX (zaraz po fs2002 pomijając fs2004) i FSUIPC z WideFS muszę poczekać na wersję wyświetlania do FSX (czy powstanie? FSX Underdev)
-
Jeśli chodzi o mnie to akurat nie zmieniło nic nic nie zaciemniło a i nic nie rozjaśniło. Ale milo, że napisałeś... Ja pytałem tylko czy po za układami stricte zaprojektowanymi do 7-seg nie zapomniałeś o pojedynczych światełkach, które w kokpicie powinny być tu i ówdzie w szczególności ówdzie
No właśnie. Gdzie ja napisałem że układy są stricte zaprojektowane do sterowania wyświetlaczy? Cały czas jest mowa o "płytkach", które mają określone możliwości. 3 płytki dla 3 kluczowych części kokpitu GLARE+MIP, OVERHEAD I PEDESTAL. Na poszczególnych płytkach znajduje się wszystko co potrzebne do obsługi poszczególnych części. Więc płytka I/O GLARE obsłuży wszystko co tam jest do sterowania, wszystkie wyświetlacze, encodery, przyciski, ledy-y "lampki". A zasadnicza różnica pomiędzy moim projektem a wszystkimi innymi polega właśnie na umieszczeniu wszyskich potrzebnych elementów sterowania na konkretnej - jednej płytce. Dla początkujących rozwiązanie droższe od OC ale docelowo jak ktoś planuje cały kokpit to jest to o wiele, wiele tańsze.
Tak naprawdę im bardziej wnikam w symulatory jako takie tym bardziej jestem przerażony ich brakami.
Ja pisząc słowo "symulator" mam na myśli np. FS9, FSX a to tak na prawdę jest zabawka i nigdy nie było to tworzone docelowo do obsługi jakiegokolwiek domowego kokpitu mniejszego czy większego. Dlatego tak jak piszesz wszystko jest mocno uproszczone. Jak pisał EGHI jeśli chcesz mieć soft rzeczywiście nakierowany na budowę kokpitu to musisz skierować się w stronę właśnie takich rozwiązań jak PM. Lub kombinować jak "koń pod górę" żeby coś więcej wydobyć z dostępnych kawałków, FSIPC, key to mouse, macros itp itd.
Nie wiem jak to rozwiązał Skalarki w Wilco, ale na pewno wszystko nie zadziała. Ja sam męczę się z pewnym samolotem i już wiem, że poza tym co daje FSX nie wycisnę wiele.
To prawda że wszystko nie zadziała ale właśnie kombinując udało mi się sporo wycisnąć. Zresztą Wilco to jest tylko na początek, docelowo cały czas mam nadzieję na samolocik AirSimmer-a, którego jedna z wersji ma być dedykowana dla kokpit-builderów więc wtedy to będzie bułka z masłem.
-
Wiele pytań, niejasności itd. Trzeba po prostu jeszcze poczekać (chyba już niedługo) i zobaczyć jak to działa w praktyce. Wtedy wiele się wyjaśni. Skalarki ruszył z projektem, vito_zm pisał kilkanaście postów wcześniej, że Damos też wkrótce powinien ukończyć swoje rozwiązania. Więc trzeba jeszcze trochę poczekać. Osobiście mam nadzieję, że jeszcze w tym roku wiele osób rozpocznie budowę swoich paneli w oparciu o polskie platformy :)
-
skalarki napisałeś parę postów wcześniej
Prezentowana płytka zawiera:
1xPIC18f4550
7xMCP23S17
3xMAX7221
+ kilka drobnych elementów
max7221 to 8x7seg (3 szt sugerują, że będzie to 8x7seg dając wynik zbliżony do 24 cyferek)
Co do symulatorów nie przeczytałeś/ nie zrozumiałeś co napisałem.
Precision simulator jest stworzony jako platforma treningowa dla pilotów B744 bez ślicznych widoczków bo i po co im to było... miał to być symulator treningowy do lotów IFR co widać zresztą po grafice 3 rzędy kropek z czerwonymi na środku to RWY.
Paru zapaleńców stwierdziło, że można by to podłączyć do domowego "symulatora" zwanego FS/flightGear i uzyskać render jaki da się w danej wersji czyli do wyświetlania scenerii używa się FS'a/FG i tylko do tego. Cały samolot jest z PS1. PS1 ma możliwość pracy w sieci na wielu komputerach jednocześnie z rozdzieleniem na poszczególne wyświetlacze co oznacza ze nie muszę kupować FD/ND/EACS/CDU od PM bo to mam to wszystko - może nie jako GL ale zawsze wystarczająco do latania.
Przy odrobinie szczęścia można spróbować odpalić główny samolot na tej samej maszynie co fs a resztę obsługiwać ze zdalnych. Ja na razie się uczę to ogarniać.
Reasumując:
Dostajesz B747-400 a musisz sobie załatwić hardware i widoczki :). Zrobiłem testowy przelot bez widoczności z EPWA do EPPO/ils29 i szczerze mówiąc niczym to się nie różniło od lotu czymkolwiek w warunkach IFR :)(pomijając kwestię skomplikowania programowania i obsługi urządzeń )
Broń Boże od wywoływania awantury w tym temacie to ma być topic rozwojowy.
Dodam tylko że panowie już pracują nad nową wersją z ładną grafiką
(http://aerowinx.com/assets/pics/PSXpreview001.jpg)
(http://aerowinx.com/assets/pics/psxAlpha29.jpg)
(http://aerowinx.com/assets/pics/psxAlpha29Lcd.jpg)
-
Jak coś to ja się też chętnie zapiszę na tę drugą opcje.
-
znalazłem jeszcze parę screenów z wersji PSx
(http://aerowinx.com/assets/pics/psxA28rmi.jpg)
(http://aerowinx.com/assets/pics/psxA28p7p6a.jpg)
(http://aerowinx.com/assets/pics/psxA28p7p6b.jpg)
Zapomniałem dodać, że sim ma być nadal Independent Platform (jak to się mówi po polsku... niezależny od systemu operacyjnego).
DOS, WINDOWS, MAC OS, MAC OS X, LINUX, *BSD
Screeny akurat z MAC OS X
-
Co do symulatorów nie przeczytałeś/ nie zrozumiałeś co napisałem.
Wygląda na to ze chyba się wogóle nie rozumiemy.
Ja nie mam zamiaru wykazywać "wyższości świąt bożego na rodzenia nad wielaknocnymi" pisząc jak sprawa z symulatorami i hardearem wygląda. Chodzi tylko o to aby ludzie wiedzieli jak najwięcej na ten temat. Dlatego w swoim długim poście powyżej opisałem jak wygląda komunikacja z urządzeniem zewnętrznym oraz symulatorem.
Natomiast jak rozumiem twój post to wręcz nakłaniasz do tego 747 opisując jaki to on wspaniały. Mi nie o to chodzi. Ja już wiem jakim samolotem będę latać i nikt mnie nie przekona do zmiany zdania.
Jeśli twierdzisz że w swoim projekcie będziesz korzystał z FSUIPC to znaczy że twoim symulatorem jest FS9 lub FSX. FSUIPC jest potrzebne tylko i wyłącznie do tego aby z FS9 lub FSX odczytywać lub zapisywać konkretne dane. Jeśli się tak dzieje w twoim przypadku to znaczy że te dane można wykorzystać np. do sterowania elementami hardwearu kokpitowego.
-
No zgadzam się, że się nie rozumiemy co najmniej w 2 pkt.
1. nikogo nie nakłaniam do zmiany z arbuza na B744 - a broń panie Boże
2. symulatorem nie będzie żaden z rodziny FS (na razie mam takie wnioski po kontakcie z PS) ani FlightGear.
2a. FS/FSX (z FSUIPC) czy FlightGear to wyświetlacz a nie symulator. Przez FSUIPC dostarczam danych o położeniu samolotu a FS tylko wyświetla render samolotem w FS może być cessna lub nawet motolotnia i to żadna różnica bo wyświetla mi tylko obraz a latam nadal B744 zatem FS nie może być symulatorem bo motolotnia nie ma związku z boeingiem.
Zgadzam się z Tobą, że ludzie powinni wiedzieć więcej o symulatorach a twierdzenie, że skoro FSUIPC to musi to być symulator FS jest nie tylko wątpliwe a mocno mylące. Dlatego właśnie iż mylisz symulator z wyświetlaczem poprowadziłem wywód na ten temat. Gdyby były scenerie lotnisk i świata dla QUAKE3 Arena to też można by zastosować go jako wyświetlacz. FS jednak jest bardziej (niż Q3Arena ) odpowiedni. Jak znajdę schemat blokowy całego założenia to zamieszczę.
-
Seeb,
z tego co piszesz wynika, że FS to Flight Display :001: a nie jak w nazwie- Simulator.
A na poważnie, wszystko to o czym piszesz działa jak Project Magenta i podobne programy symulujące SYSTEMY samolotów. Gdyby się dało łączyć tak łatwo różnej maści programy, to już dawno miał bym najbardziej wypasiony Sim na świecie. Jeśli Precision Simulator współdziała z FSUIPC to znaczy, że ktoś wziął pod uwagę to, że można ten System odpalić w FS. Tylko powiedz mi, czy poza samym modelem lotu potrafi odczytać inne parametry? np. ciśnienie, siłę i kierunek wiatru itp?. Nie znam tego 747, więc mogę się mylić. Ale wydaje mi się, że tak to działa.
-
Być może mylę symulator z wyświetlaczem.
Fakt że nie znam nic innego poza FSX, FS9 no i ostatnio FALCON.
Zgadzam się z Tobą, że ludzie powinni wiedzieć więcej o symulatorach a twierdzenie, że skoro FSUIPC to musi to być symulator FS jest nie tylko wątpliwe a mocno mylące.
Natomiast tu się nie zgadzam absolutnie FSUIPC służy TYLKO I WYŁĄCZNIE do komunikacji z FS9 lub FSX (dawniej ze starszymi wersjami) i do nieczego innego go nie można podłączyć.
-
Dokladnie jak napisałeś Flight display to dobra nazwa na to co zostało z FS'a.
Tak! jednym słowem ale czy to cie satysfakcjonuje? Chyba nie ... to o czym piszę działa - Matt Sheil ma symulator w domu ... najbardziej wypasiony na świecie ... Właśnie zbudowany na Precision Simulator 1.3 + Flight Display ;) 2004 :)
dziala z VATSIM
odczytuje pogodę i reaguje na warunki atmosferyczne
posiada wbudowany radar pogodowy
czarna skrzynkę i FMC, ND i całą resztę niedługo będzie wznowiona produkcja danych w navgraph
http://www.hoppie.nl/pub/ więcej informacji o PS
http://www.hyway.com.au/747/2006-1.htm najfajniejszy symulator świata (domowy) faza z 2006
http://aerowinx.com/forum/topic.php?id=173 - ten sam sim tylko 3 lata później... 2009 listopad
Co do fsuipc nie brałeś pod uwagę ze to symulator się komunikuje przez FSUIPC z wyświetlaniem(FS) a nie sprzęt do którego został napisany.
Żeby zdjąć Ci z głowy FS'a to powiem tak: Bez FSUIPC i FS2004, FSX tez polatam.
Użyję do wyświetlania np FlightGear a Na przyszły rok nie użyję niczego bo PS będzie miał własny render GL taki jak widziałeś powyżej na screenach. Podobno ma mieć scenerie kompatybilne z obecnie znanymi sim'ami domniemuję, że chodzi o FS* i FG ale pewności nie mam.
Próbuję Ci otworzyć oczy na inne rzeczy natomiast uparłeś się nazywać symulatorem coś co w tym wypadku nijak nie jest tym czym chciałbyś by był.
-
Ok, skoro takie to proste, to odpal go w Falconie.
A Matt Sheil lekko przesadził zwłaszcza z ilością komputerów, popraw mnie jeśli się mylę- ponad 10? wydał na to 240.000 dolarów?Taki 747 można dużo taniej wybudować, i będzie taki sam efekt.
Zdania nie zmienię, że Microsoft Flight Simulator to symulator lotu, nie "wyświetlacz". Mamy przestrzeń w której można się poruszać, jakiś środek lokomocji - samolot, taki czy inny nawet ten Twój 747, można przelecieć lub kołować ;) z punktu A do punktu B. Jest to więc symulator lotu. Może mniej realny od tych profesjonalnych, ale jednak jest. Natomiast bez całej tej oprawy ten 747 jest tylko symulatorem samolotu, jego awioniki, wszystkich systemów pokładowych + jakiś marny widok za okno, który rzeczywiście jest najmniej istotny.
-
troszkę meczące jeśli do komputera wsadzisz tuner tv stanie się telewizorem czy będzie komputerem?
jadać dalej twoim tokiem myślenia ... jeśli jest telewizorem to po co komu w domu taki telewizor a jeśli nadal jest komputerem to dlaczego można oglądać telewizje i tu pozostajesz przy swoim kiedy włączasz tuner to telewizor jest telewizorem a nie komputerem mimo ze tuner jest karta tv.
A przecież można prościej jeśli komputera używam z kartą tv to jest nadal komputerem z możliwością oglądania tv.
Zdania nie zmienię, że Microsoft Flight Simulator to symulator lotu, nie "wyświetlacz".
Dla mnie to symulator wtedy gdy coś symuluje, kiedy nie symuluje to tylko wyświetla to proste jak drut.
Bo przecież komputer nie staje się odtwarzaczem blue-ray kiedy podłączysz do niego odtwarzacz a tylko wtedy gdy coś odtwarza bez zewnętrznego odtwarzacza.
Po głębszym przemyśleniu na potrzeby tego tematu: Nie użyję do wyświetlania FS* a nawet odinstaluję zatem nie będzie niczego symulował nie będzie do niego nic podłączone zatem PS pozostanie symulatorem jak to nazwałeś "realny od tych profesjonalnych" ten jest bardziej - został zaprojektowany do treningu pilotów samolotów pasażerskich zatem jest elementem szkolenia pilotów (raczej był). Żeby zakończyć off-topic. Mamy do oprogramowania 4 różne symulatory: Falcon, FS , FG (FlightGear) i PS każdy istnieje bez innych a niektórym przydadzą się pozostałe.
Proponuję skupić się na meritum a nie jałowych dyskusjach...
WSZYSTKO ZALEŻNY OD ZASTOSOWANIA A NIE OD NAZWY.
-
196 000$, 14 komputerów ... nie wiem czy można taniej full motion zbudować... pewnie tak, w Polsce na pewno. Pewnie parę układów mniej by działało ale prawie byłby identyczny ale jak nawet reklamy piwa dowodzą prawie czyni różnicę - jak dużą sam oceń.
-
Mamy do oprogramowania 4 różne symulatory: Falcon, FS
-raczej "wyświetlacze" :003:
Nie ma o co spierać się. Rozumie, że ten 747 to samowystarczalny symulator kokpitu do którego można podłączyć np. FS jako widok za okno.
Pytanie z innej beczki- wytłumacz mi w jaki sposób chcesz podłączyć do tego hardware? za pośrednictwem jakiegoś softu? czy bezpośrednio, sam symulator ma taką opcje. Jak to działa?
-
Jest API wprawdzie dość rozrzucone bo projekt ma swoje lata ale jak sądzę uda się to zebrać do kupy dzięki temu, że wersja 1.3 zostala wyprzedana dopiero w tym roku.
...do którego można podłączyć np. FS jako widok za okno
No i o to chodziło... (nie musi ale FS jest najbardziej znany)
Projektów kokpitów jest sporo forum aktywne a najbardziej szalony z kokpitów amatorskich jest oparte na tym projekcie co sugeruje, iż uda się wszystko poskładać. No nie wspomnę że istnieje do tego ponad 350 stronicowy manual.
Tak tylko nadmienię ze nadinterpretacja tez jest nadużyciem (każdy z osobna coś symuluje więc 4 symulatory), ale w końcu coś bardziej do rzeczy.
-
jeśli faktycznie uda mi się po FSUIPC i WIDEFS podłączyć widoki scenerii z FSX
Może to Cię zainteresuje? http://www.wideview.it/
-
Śledzę z uwagą ten wątek i muszę przyznać,że seeb wprowadził coś nowego do tematu tzn.wprowadził weryfikację pojęcia symulator jednocześnie podniósł trochę poprzeczkę. Przejrzałem linki do projektu Matt Sheil i jestem pod wrażeniem.Sprawdziłem w Google hasło Precision Simulator B744 i mam teraz ogólny pogląd.
Moje wnioski są następujące.
1.Bardzo dobrze,że są tacy "wizjonerzy"jak seeb ponieważ dzięki nim jest postęp.
2.Na tym forum jest bardzo skromna liczba osób mająca ambicję zbudowania domowego kokpitu.Wątek w którym jest o tym mowa jest raczej marginalny.Są fora wyspecjalizowane związane z budową kokpitów dla określonych "symulatorów".W moim przypadku viperpits.
3.Budując kokpit trzeba zadać sobie pytanie dlaczego to robimy.W moim przypadku odpowiedź jest prosta.Zabawa z "symulatorem" Falcon traci sens jeśli trzeba korzystać z klawiatury.
4.Niezależnie od tego czy mieszkamy w Polsce czy zagranicą budowa kokpitu jest związana z kosztami,dlatego na tym forum próbujemy je minimalizować.
5.Mam świadomość,że buduje się wspaniałe kokpity dla różnych "symulatorów",ale ja realizuję to co jest optymalne z mojego punktu widzenia.
Na koniec kilka uwag ogólnych.Nie ma sensu udowadniać sobie kto ma rację,ponieważ każdy realizuje swój projekt na bazie swojej wiedzy, możliwości oraz potrzeb.Budowa kokpitów jest dosyć kosztownym hobby i wymaga pewnych umiejętności.
Większość z nas na tym forum cieszy fakt,że powstają 2 polskie "platformy" dla "symulatorów".Dla naszych skromnych potrzeb to wystarczy.Obawiam się,że w Twoim seeb przypadku może to być za mało.
-
Odbiegając od ostatniego "gorącego" tematu o symulatorach i wyświetlaczach, nieskromnie informuje, że na stronie http://fs.angus.foxnet.pl/ udostępniłem moduł do obsługi kontrolerów gier. W tym momencie można już próbować obsługiwać np. wszystkie przyciski dostępne w MJoy, enkodery wykorzystać do zmian częstotliwości itd. itp.
-
Moje gratulacje codeking.Tak myślę,że wykonam fragment platformy skalarki i gdy będziesz miał jakiś fragment programu pod Falcona rozpocznę testy ucząc się jednocześnie pisania skryptów.
-
codeking,
kapitalnie wszystko działa :). Mjoy sprawdzony i jest ok. Przetestowałem także kontroler BU0836 i program od razu odnalazł kartę. Początkowo pojawiły się tylko 20 przyciski, ale po chwili wskoczyły wszystkie. Niestety nie widzi osie i jest tylko jeden hat. Ale powodem tego jest (chyba) to, że żaden potencjomert nie był podpięty.
Gratuluje.
-
Początkowo pojawiły się tylko 20 przyciski, ale po chwili wskoczyły wszystkie.
Czy chodzi Ci o ten dziwny efekt z paskiem przewijania ? To jest jakiś błąd do poprawienia.
Niestety nie widzi osie i jest tylko jeden hat. Ale powodem tego jest (chyba) to, że żaden potencjomert nie był podpięty.
Na forum supportu do tego kontrolera znalazłem informację, że jak nie podłączysz potencjometru to dana oś nie będzie widoczna. Martwi mnie brak przełączników HAT :/ Na stronę http://angus.foxnet.pl/fs/blog/?page_id=49 wrzuciłem wersję 1.0.0.1 modułu do kontrolerów, dodałem przycisk "Raport..." w oknie konfiguracji modułu. Jeśli możesz wygenerować taki raport i podesłać, to będę wdzięczny.
-
Dokładnie o ten efekt mi chodziło. Kiedy przewinę kilka razy kółkiem myszki pojawiają się wszystkie przyciski. Z Hat jest taka sama sytuacja jak z osiami, nie jest to żaden błąd, musi być coś podłączone. Raport prześlę Ci jeszcze dziś.
Pytanie do Skalarki:
Na wyświetlaczach 7-segment wspólna katoda? czy anoda? Jakie Ty stosujesz?
-
Wyświetlacze ze wspólną katodą - niestety albo stety.
-
Witam
Gratulacje codeking - udało mi się uruchomić mjoya i sterować nim flight simulatorem. Na razie była to prosta rzecz a mianowicie sterowanie parking break. Wszystko działa ok, poza podłączaniem samego mjoya, początkowo widać tylko 20 przycisków, jak wybiorę go jeszcze raz to pojawia się reszta. Osie widać, ale jest tylko jeden HAT.
Co do samego skryptu to na początek wybrałem coś bardzo prostego, ponieważ moja wiedza na temat ich pisania jest prawie zerowa, ale chyba zaczną się uczyć / raczej na pewno :001:/. Mam więc prośbę o opisanie zupełnych podstaw pisania skryptów / pewnie takich jak ja jest więcej / a program daje tak duże możliwości, że będzie wielu chętnych, ewentualnie do jakiego języka skryptowego jest najbardziej podobny to sam coś poszukam, lub jakieś strony odnośnie podstaw pisania skryptów.
Wracając do samego programu to jest to rewelacja, od dłuższego czasu szukałem softu dzięki, któremu wszystkie przyciski mjoya będę mógł użyć do sterowania fs-em / bez uzycia skrótów klawiaturowych - svmapper/, a tu wszystko jest - super.
Mam też parę pytań :
- W najnowszej wersji / od 3.81 / FSUIPC pojawiła się możliwość tworzenia makr. Jest to bardzo fajna sprawa / dotyczy samolotów, do których nie ma offsetów np. PMDG 737NG /, więc mam pytanie czy przewidujesz możliwość sterowania tymi makrami poprzez moduł FSDataOutput - wtedy nie było by problemu z wszystkimi samolotami - może poprzez virtual button
- czy będzie moduł do sterowania LCD - takich jak FSLCD - mam zrobiony gotowy układ, który działał. Tu / http://www.mikkila.org/fsbus/lcd/index_e.php / jest schemat na podstawie, którego zbudowałem ten układ.
Czekam z niecierpliwością na kolejne moduły w tym do sterowania skrótami klawiaturowymi - do pmdg rzecz wręcz konieczna. Jestem pod wielkim wrażeniem jakie ta aplikacja ma możliwości. Do tej pory musiałem kombinować z wieloma programami / svmapper, fslcd, / a teraz będzie wszystko w jednym miejscu.
pozdrawiam i jeszcze raz gratuluje - Zając
-
Wszystko działa ok, poza podłączaniem samego mjoya, początkowo widać tylko 20 przycisków, jak wybiorę go jeszcze raz to pojawia się reszta. Osie widać, ale jest tylko jeden HAT.
Problem z wyświetlaniem jest po prostu moim błędem :) Do poprawy oczywiście.
MJoy ma tylko jeden HAT, program traktuje go jako specjalny przycisk reprezentowany przez zmienną typu int. Jeśli poruszymy HATem to widać, że wartość w tabeli (w wierszu dla przełącznika HAT) zmienia się. Myślałem oczywiście nad rozbiciem tego na 8 zwykłych przycisków, być może zrobię to jako opcję.
Mam więc prośbę o opisanie zupełnych podstaw pisania skryptów / pewnie takich jak ja jest więcej / a program daje tak duże możliwości, że będzie wielu chętnych,
Starałem się na stronie opisać od początku wszystko co i jak, jeśli coś jest niejasne to spróbuję to "rozjaśnić" :) Tak więc kto pyta nie błądzi :)
ewentualnie do jakiego języka skryptowego jest najbardziej podobny to sam coś poszukam, lub jakieś strony odnośnie podstaw pisania skryptów.
W sumie to on do niczego niepodobny :) Składnia jest prosta, ma jeszcze wiele ograniczeń, ale chciałem na początek skupić się na tym by to ruszyło, później będzie czas na rozwijanie języka.
Mam też parę pytań :
- W najnowszej wersji / od 3.81 / FSUIPC pojawiła się możliwość tworzenia makr. Jest to bardzo fajna sprawa / dotyczy samolotów, do których nie ma offsetów np. PMDG 737NG /, więc mam pytanie czy przewidujesz możliwość sterowania tymi makrami poprzez moduł FSDataOutput - wtedy nie było by problemu z wszystkimi samolotami - może poprzez virtual button
Nie posiadam pełnej wersji FSUIPC i nie mam tego jak sprawdzić, ale jeśli masz już jakieś makra to proponuję spróbować zdefiniować zmienną...zonk. Przy imporcie zmiennych do konfiguracji programu, wypadły offsety do obsługi makr. Więc muszę to poprawić. Postaram się dzisiaj udostępnić poprawiony plik konfiguracyjny do modułu.
- czy będzie moduł do sterowania LCD - takich jak FSLCD - mam zrobiony gotowy układ, który działał. Tu / http://www.mikkila.org/fsbus/lcd/index_e.php (http://www.mikkila.org/fsbus/lcd/index_e.php) / jest schemat na podstawie, którego zbudowałem ten układ.
To jest prościutki układ, problem w tym, że nie posiadam biblioteki do sterowania tak podpiętymi wyświetlaczami. Ktoś z tego forum miał mi taką bibliotekę udostępnić ale jakoś poszło w zapomnienie. Obsługa takich wyświetlaczy będzie w projekcie Damosa i Skalarki, więc można poczekać na te urządzenia. Ale jeśli znajdzie się taka biblioteka to dorobię taki moduł.
Czekam z niecierpliwością na kolejne moduły w tym do sterowania skrótami klawiaturowymi - do pmdg rzecz wręcz konieczna. Jestem pod wielkim wrażeniem jakie ta aplikacja ma możliwości. Do tej pory musiałem kombinować z wieloma programami / svmapper, fslcd, / a teraz będzie wszystko w jednym miejscu.
To chciałem uzyskać, takie "all in one", mam nadzieję, że to się nie odbije czkawką ani mi ani użytkownikom. Obsługa klawiatury - wkrótce :)
-
Podczas przekopywania Ebay natknąłem się na to :
http://cgi.ebay.com/F-16-Viper-Fighting-Falcon-Cockpit-Display-Simulator_W0QQitemZ170405328517QQcmdZViewItemQQptZUS_Software?hash=item27acf2f685
Glass cockpit F16 za 24,99$
Więcej tutaj: http://www.flight-dynamix.com/f-16sims.html
-
Z tego co przeczytałem wynika,że można kupić różne wersje kokpitu F16 w zależności od potrzeb.Bardziej interesująca jest propozycja Glass cockpit F16 za 24,99$.
Czy dobrze rozumuję.Jest to program,który współpracuje z FSX i można na LCD (dotykowym) wyświetlać informacje jednocześnie można przełączać niektóre przełączniki?Czy może ktoś wyjaśnić co konkretnie Glass cockpit F16 robi i z czym współpracuje?
-
Może kodujących do projektu skalarki to zainteresuje:
http://aerowinx.com/forum/topic.php?id=129
-
Bardzo interesujący projekt.Seeb ty jesteś na bieżąco w temacie,czy możesz w paru słowach wyjaśnić czy PSX jest już stosowany czy jest w fazie projektu.Ja zrozumiałem,że jest to uniwersalny program do stosowania w istniejących i przyszłych projektach (jest też mowa o OpenCockpits).
-
Więc tak:
primo PSX jest to kontynuacja Precision Simulator 744 (747-400) obecnie jest w fazie końcowej i zapowiadany jest na 1 kwartał 2010 cena ok 500$ - zależny od zainteresowania - im większe tym taniej. Został całkowicie napisany od nowa (przecież nikt już nie używa turbo Pascala ;) ) a zważywszy independent platform jako język wybrana została Java (z jednej strony dziwne bo jakoś szaloną szybkością ona nie grzeszy ale za to można nawet na komórkę to napisać).
Dla wyjaśnienia PSX oznacza "Precision Simulator 10.0" tak jak by miał mieć coś wspólnego z FSX ;) ale nie mój w tym problem co i jak się nazywa :)
Aktualnie jeśli ktoś chce coś napisać żeby z tym działało to najlepiej już teraz przygotować zainteresowanie jest spore a wsparcie sprzętu od dnia premiery pomaga sprzedawać ów sprzęt, Dlatego zwróciłem uwagę na ten temat.
Generalnie większość producentów np FlightGear pisze już sterowniki do PSX z symulatorem poprzedniej generacji działają wszystkie znane platformy w tym OC,FSBUS etc teraz FSbus jest jeszcze nie wspierany z tego co wiem ale ma być tylko chętnego nie ma do napisania sterowników :)
Dla pocieszenia powiem, że większość kodu ADD-ON to kod w C/C++ wiec jazdy wielkiej nie będzie. Mile widziane wsparcie sterowników dla linuxa bo cześć ludzi siedzi na BSD i LINUXIE.
Być może kiedyś rozrośnie się o jeszcze jakieś samoloty tego nie wiem a do premiery się za wiele też nie dowiemy.
Jak o czymś zapomniałem to pytajcie jak wiem to dopowiem :)
-
Nieśmiało zapraszam na moją stronkę - nowa wersja aplikacji DomowyKokpit + moduł do obsługi klawiatury.
Kolejna dobra informacja to płytka Skalarki. Działa bez żadnych problemów i moduł do obsługi płytki jest już implementowany. W tym miejscu dziękuje EGHI za przekazanie mi tej płytki do testów, i dzięki dla Zająca za płytki z wyświetlaczami 7-LED do testów oraz uwagi związane z aplikacją.
-
Moje gratulacje codeking.Więcej takich optymistycznych wiadomości.
-
Po pracowitym weekendzie mam do zaprezentowania kolejną płytkę z cyklu SKALARKI I/O project. Zapraszam na www.a320-project.skalarki.co.uk (http://www.a320-project.skalarki.co.uk) gdzie można zobaczyć parę fotek i opis płytki.
Również dla tej płytki moje oprogramowanie jest tylko kompatybilne z FS9 lub FSX ale mam nadzieję iż dzięki codekingowi płytkę będzie można swobodnie zapiąć do różnych simów.
Zresztą wiem że już prace trwają i kolejna wersja Domowego Kokpitu pewno będzie zawierać obsługę podstawowych funkcji płytki.
Wielkie dzięki również dla EGHI, który jako pierwsz wsparł projekt :002:
-
Hmm no fajnie z tymi silnikami ... a czy da się sterować 4 silnikami krokowymi ? bo mój samolocik jest 4 silnikowy a i Arbuzy bywają 4 silnikowe... (no akurat 320 nie ale 340 już tak...)
-
Bardzo mi się podoba projekt skalarki.Porównuję go do rozwiązań OC i muszę przyznać,że jest konkurencyjny.To,że jest ukierunkowany na A320 nie jest jego wadą.Gdybym umiał programować uP zrobiłbym podobny projekt pod Falcona.To,że projekt jest ukierunkowany pod konkretny symulator z możliwością rozbudowy daje twórcy możliwość jego ukończenia w realnym terminie.
Myślę,że ten projekt robiony pod A320 można zastosować do Falcona z poziomu oprogramowania zewnętrznego to co robi codeking.
-
Hmm no fajnie z tymi silnikami ... a czy da się sterować 4 silnikami krokowymi ? bo mój samolocik jest 4 silnikowy a i Arbuzy bywają 4 silnikowe... (no akurat 320 nie ale 340 już tak...)
Eee no Seeb, bo ja nie kumam... o czym ty do mnie rozmawiasz.
Co mają wspólnego silniki krokowe z silnikami samolotu - jaki by on nie był?
-
Ech sądziłem, że silniki krokowe mają sterować manetkami (oczywiście widzę, że się mylę) w trybie autopilota - motorised throttle quadrant
Zatem do czego są przewidziane?
-
Manetki w Arbuzie nie poruszają się same. Silniki krokowe będą sterować kołem Trim- zgadłem Skalarki? :)
-
Tak na marginesie do 737 tez by potrzeba 4 silników (2 x manetki 2x trim), 747 nie ma kola trim, więc też 4 silniki ale tylko do manetek (rozważałem 5 silnik na potrzeby hamulca aerodynamicznego)
-
Ech sądziłem, że silniki krokowe mają sterować manetkami (oczywiście widzę, że się mylę) w trybie autopilota - motorised throttle quadrant
Zatem do czego są przewidziane?
W moim przypadku tak jak pisze EGHI to koło trymera, no a dla bardziej ambitnych budowniczych - silników krokowych używa się we wszelkiego rodzaju gaugesach np Altimeter, vertical speed etc.
Generalnie jest to zasygnalizowanie możliwości i w sumie to silników krokowych można podłączyć wg zasady ilość wyjść/4 (bo tyle linii trzeba do sterowania silnika). |To samo dotyczy wyświetlaczy LCD - też potrzebują 4 linii z danymi.
-
seeb,
w Twoim przypadku ta karta http://www.opencockpits.com/catalog/servo-motors-card-p-42.html?cPath=21_32 jest chyba najlepszym rozwiązaniem. Tylko, czy takie servo poradzi sobie z dźwigniami?
-
będzie to gdzieś opisane? myślę, że gaugesów wielu robić nie będzie... ale motorised thr owszem :)
będzie gdzieś dostępne jakieś SDK, jakiś wirtualny tester zanim doczekam się na coś fizycznego?
Chce uniknąć mieszania konfiguracji sprzętowej... dlatego na razie czekam aż wycenisz płytki i inne rzeczy zanim zabiorę się dalej.
Co do samego czy da radę to da bo to nie jest przecież wszystko co związane ze sterowaniem silnikami krokowymi ... ale o tym to ty sam dobrze wiesz
-
Codeking pracuje nad modułem do obsługi projektu Skalarki. Będzie można testować na "sucho" wejścia, wyjścia, wyświetlacze. Czy będzie sterowanie silnikami? chyba jeszcze nie, ale w przyszłości możliwe, że tym też się zajmie. Polecam już teraz lekturę na tej stronie http://angus.foxnet.pl/fs/blog/. Ja się już katuje tym mało zrozumiałym dla mnie językiem :008:
-
będzie to gdzieś opisane? myślę, że gaugesów wielu robić nie będzie... ale motorised thr owszem :)
Opisane wszystko będzie jeśli będzie zainteresowanie. Na razie szczegółowe informacje dostępne są tylko dla użytkowników jak EGHI np.
będzie gdzieś dostępne jakieś SDK, jakiś wirtualny tester zanim doczekam się na coś fizycznego?
SDK jest tylko potrzebne dla progamistów, którzy by chcieli napisać swój soft do sterowania płytkami mojego projektu. Codeking jest tu najlepszym przykładem. Dostarczam mu wszystko co trzeba aby jego soft dogadał się z moimi płytkami. Nikomu innemu się to nie przyda bo i po co.
Wirtualny tester? Hmm jeśli myślisz o sofcie no to w twoim przypadku raczej będzie kiszka, bo jak wiem to twój samolocik jest mało standardowy.
Jeśli chodzi od FS9 i FSX to mój soft bedzie się dogadywał z tymi "symulatorami" :002: natomiast codeking uwzględnia jeszcze Falcona w swoim sofcie. Ja mam sporo zrobione do A320 i aplikację do tego samolotu mogę udostępniać do testowania. Nie wiem jak daleko lub jak blisko jest codeking.
Co do samego czy da radę to da bo to nie jest przecież wszystko co związane ze sterowaniem silnikami krokowymi ... ale o tym to ty sam dobrze wiesz
Możesz doprecyzować? To pytanie czy stwierdzenie?
Wszystkie ceny bęą podane w ciągu 2 tygodni. Cały czas dopracowuję konfigurację, żeby była troszkę bardziej uniwersalna. Więc na płytkach będzie jeszcze więcej sprzętu.
-
Tylko w gwoli przypomnienia ja nie będę tego projektu używał pod FS tylko pod PS1/PSX. Zatem wprawdzie zacne prace codekinga raczej nic(lub niewiele) mi nie dadzą. A na koniec czeka mnie jeszcze PS1 motion... (ale to będzie już finalna robota kiedy dom będzie na to gotowy [na razie jest na deskach]). Nie wiem czy brałeś pod uwagę to, że ktoś będzie chciał budować platformę full-motion.
Ja jestem zainteresowany bo na razie jestem zdany sam na siebie! (właśnie reanimuję wiedzę o C!).
No jeszcze po za samymi sygnałami trzeba doprowadzić im prąd - nie wdając się w szczegóły techniczne ciężko sobie wyobrazić 2A i 24V, 30V czy 40V z USB :) dokładniej opisane sterowanie silnikami krokowymi na forum cncinfo.
-
No jeszcze po za samymi sygnałami trzeba doprowadzić im prąd - nie wdając się w szczegóły techniczne ciężko sobie wyobrazić 2A i 24V, 30V czy 40V z USB :) dokładniej opisane sterowanie silnikami krokowymi na forum cncinfo.
No oczywiście że racja. Ale doprowadzenie zasilania do silnika to już zadanie dla modułu wykonawczego. Dla najmniejszego silniczka wystarczy zasilanie płytki. Nie jest ono relizowane z USB tylko z zewnętrzengo zasilacza małej mocy. Natomiast dla większych silników trzeba dodać odpowiednio dobrany moduł wykonawczy żeby to pociągnąć.
-
To jak z tym SDK? bo o to też pytałem/prosiłem mile widziane c/c++
Co do "wirtualnego testera" myślałem bardziej o czymś co software'owo udaje płytkę żeby wiedzieć jak się to zachowa kiedy ... (tu długa lista możliwości płytki) i co wyśle do mojego (codekinga czy ktokolwiek będzie chciał coś napisać do komunikacji z twoją płytką) softu.
-
seeb,
właśnie podałeś mi pewien pomysł. Może udało by się wykorzystać sterownik silników krokowy z CNC, lub dużego plotera do sterowania platformą? Zwykle są trzy osie, czyli trzy silniki a do platformy tyle chyba wystarczy. Problem to program, może codeking pokusił by się na to? :). Co do aplikacji codekinga to chyba się mylisz, kwestia napisania odpowiednich skryptów i jestem przekonany, że to zadziała z PS1/PSX.
-
Oczywiście nie przekreślam sprawy ale sterowniki i tak trzeba by napisać dla ps1.
Silniki z CNC nadadzą się do F16 na B744/Arbuza dowolnej serii nie da rady musiało by to dźwigać jakieś 2 tony złomu na sobie (sam ekran 7,8m na 2,5m musi ważyć) i raczej ciężko znaleźć odpowiednio duże i wytrzymałe zębatki w amatorskich warunkach za to pneumatyka jak najbardziej zda egzamin
-
seeb, jak Ci zbywa 50,000$ to kup to:
http://www.inmotionsimulation.com/
po co się męczyć? :004:
-
Jak będzie zbywało napewno kupie ;) narazie płacę kredyty i muszę jeszcze do tego oszczędzać na budowę domu - sima full motion nie wstawię do mieszkania w bloku w dodatku ze skorupą i ekranem (wielkość wyżej)
-
To jak z tym SDK? bo o to też pytałem/prosiłem mile widziane c/c++
Nestety SKD jest tylko dla C#, jeśli będziesz chciał to nie ma sprawy.
Co do "wirtualnego testera" myślałem bardziej o czymś co software'owo udaje płytkę żeby wiedzieć jak się to zachowa kiedy ... (tu długa lista możliwości płytki) i co wyśle do mojego (codekinga czy ktokolwiek będzie chciał coś napisać do komunikacji z twoją płytką) softu.
Takie coś to ja mam zrobione w Proteusie, tak zaczynałem projektować całość, zanim zrobiłem prototyp żeby uniknąć błędów. Tylko po co symulować coś co istnieje - płytki są gotowe. W połowie grudnia zamawiam kolejną partię już z naniesionymi poprawkami. Natomiast pełen opis tego co soft ma wysłać (komendy, dane itp.) oraz co płytka ma odpowiedzieć zwrotnie jest w SDK.
-
Jak możesz daj SDK. Zobaczę może uda mi się nauczyć C# na tyle żeby coś napisać ... szkoda tylko, że w C# bo raczej nie sądzę żeby udało się to odpalić na linuxie/bsd
-
Polecam już teraz lekturę na tej stronie http://angus.foxnet.pl/fs/blog/. (http://angus.foxnet.pl/fs/blog/.) Ja się już katuje tym mało zrozumiałym dla mnie językiem :008:
Pytaj na forum jeśli jest coś nie jasne, więcej osób przeczyta i odpowiedź nie zginie :)
Ja jestem zainteresowany bo na razie jestem zdany sam na siebie! (właśnie reanimuję wiedzę o C!).
Chętnie pomogę, tylko nie da się wszystkiego zrobić naraz :) Plan jest taki, żeby na Mikołaja był gotowy moduł do obsługi małej płytki od Skalarki. Później dodać obsługę większej płytki i będę mógł zająć się kolejnymi modułami, myślę, że zrobienie obsługi PS1 jest jak najbardziej realne. Być może nawet można by połączyć siły, Ty napiszesz kawałek w C/C++ a ja to wykorzystam w C#. Nie znam jeszcze dokładnie SDK od PS1 więc nie wiem jak jest skomplikowane. Tak jak napisałem, płytki Skalarki mają pierwszeństwo bo to są długo oczekiwane urządzenia które można wykorzystać.
-
Nie istnieje SDK do PS1 większość rzeczy robi się z reverse enginering Borland Turbo Pascal więc robota nie jest przyjemna ale nie jest tragicznie Broker ma opis no i jest Ivan Ngeow kolega z Singapuru, który chętnie pomaga a jest autorem wielu dodatków i modyfikacji.
-
Przepraszam, że się wtrącam w wątek, ale mam takie info: trochę nawiedzeni elektronicy z firmy używają do swoich pet projektów routerów. Wygląda to tak:
http://www.omnima.co.uk/store/catalog/Embedded-controller-p-16140.html albo tak http://www.linux-mips.org/wiki/BR6104
Można wgrać na to swojego Linuxa z http://squidge.sourceforge.net/ albo http://openwrt.org/
Masz komputer, port USB, sieć, wyjście via LEDy routera na cokolwiek ( wyświetlacz ciekłokrystaliczny czy np. karta SD - http://squidge.sourceforge.net/mmc/ albo kamerka http://squidge.sourceforge.net/webcam/ )
Coś po polsku w tym temacie: http://images.google.pl/imgres?imgurl=http://lh3.ggpht.com/mlodedrwale/SBMMmloppwI/AAAAAAAACGU/WWfw_gpWR7s/14.jpg&imgrefurl=http://www.mlodedrwale.pl/page/2/&usg=__u6SCnbyJCYUwANITqJwc-VhOVTI=&h=1367&w=1000&sz=251&hl=pl&start=11&sig2=L9EBhLdH-WrBiX3DgKZhag&um=1&tbnid=Sb5FgAcIBHcOQM:&tbnh=150&tbnw=110&prev=/images%3Fq%3Dbr6104k%26hl%3Dpl%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26sa%3DN%26um%3D1&ei=yw8VS5DgPNPFsAaeqI3KBA
Nie wiem, czy to kogoś zainteresuje, ja spasowałem, wolę od razu "fabryczny" mikrokompek z Linuxem oprogramowywać (bo jestem noga jeśli chodzi o lutownice), ale kto wie? Może ktoś się tutaj zainteresuje...
Pozdrowienia!
-
Dzięki za info.
Wygląda nieźle, cena i możliwości zachęcające do eksperymentów :) Trzeba pomyśleć jak to wykorzystać do "naszych" celów, może byłaby to ciekawa platforma do projektu Damosa.
Ciekawe czy pod to USB można podpiąć hub USB.
-
Pewnie można jak i pewnie można wszelakie HID'y podłączyć
-
Czy ktoś myślał a może nawet próbował wykorzystać układ ze standardowej klawiatury PC (pod PS2) do wykorzystania jako układ wejść/przycisków ? Nie mam na myśli podpinania jej bezpośrednio do PC ale do uC. Obsługa w uC i wysyłanie do PC (RS232 lub USB) danych przetwarzanych przez specjalny program. Nie wiem jak taki układ klawiatury zachowa się w przypadku np. naciśnięcia połowy klawiszy na klawiaturze. Obsługa takiej klawiatury w uC nie jest trudna, dałoby to ponad 100 dodatkowych klawiszy/przycisków za niewielką cenę.
-
Ja to testowałem na początku mojej kariery budowniczego kokpitów.Prześledź ten wątek.
http://www.il2forum.pl/index.php?topic=8494.0
Dałem sobie spokój,ponieważ jest problem z tego co pamiętam z naciskaniem kilku klawiszy jednocześnie.Dokładnie nie pamiętam,ponieważ było to dawno temu,ale jest ślad w wspomnianym wątku.
-
A ja, podobnie jak vito też na początku kariery testowałem ale nie dałem sobie spokoju i powstało takie coś:
http://img4.imageshack.us/img4/6755/p9100136.jpg
Ta skrzynia miała obsługiwać ( i nadal to robi) MCDU w VasFmc. Wydłubałem z klawiatury sterownik, dolutowałem kable i wszystkie klawisze numeryczne, alfabet oraz po sześć z każdej strony ekranu są podłączone do tego sterownika. Jak wspomniał vito nie da się tego użyć w sytuacji, kiedy trzeba wcisnąć kilka klawiszy. Nie może też być wciśnięty żaden przycisk na stałe, czyli odpadają wszelkie toggle, rotarry itp. Można podłączyć chwilowe przyciski, warunek jeden- przypisany tylko jeden klawisz klawiatury.
Poniżej widok na kłęby kabli, kiedy jeszcze nie wpadłem na to, że można samemu wytrawić płytkę PCB :001: ( proszę się nie nabijać, to moje pierwsze natchnienie :020: )
http://img46.imageshack.us/img46/4632/p9100137.jpg
http://img269.imageshack.us/img269/7217/p9100135.jpg
Dodam jeszcze, że sterownik z klawiatury USB. Nie przeszkadzało mi to w obsłudze zwykłej klawiatury, obie działały na jednym kompie.
Codeking,
jeśli jesteś w stanie napisać taki program, w którym po wciśnięciu jednego klawisza można będzie przypisać kombinacje kilku, to do przycisków jak najbardziej można stosować taki układ.
-
Nie zrozumieliśmy się :) W swoich rozwiązaniach próbowaliście podpiąć przyciski do klawiatury podpiętej bezpośrednio do PC, czyli takiej, z której normalnie się korzysta. Natomiast ja myślę o podpięciu klawiatury (starej z łączem PS/2) do mikrokontrolera np. AVR. W nim zrobić obsługę klawiatury (ATMEL udostępnił nawet kody źródłowe do tego :) ) i z niego wysyłać do komputera (np. przez RS232) informacje typu "naciśnięto/zwolniono przycisk numer X". Te informacje byłyby przetwarzane przez odpowiedni program (np. moduł w DomowyKokpit). Mam tylko obawę o to, że np. w przytoczonym dokumencie od ATMEL'a (http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF (http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF)) wspominają oni o tym, że długie naciśnięcie klawisza powoduje, że sama klawiatura wysyła 10 razy na sekundę informację o naciskaniu tego klawisza. Kłóci mi się to trochę z tym, co można ustawić w panelu sterowania w Windows, w aplecie "Klawiatura". Najlepiej pewnie będzie sprawdzić to w praktyce, tylko potrzebny jest czas, ale pokusa duża bo ponad 100 przycisków za małą cenę.
-
Jest to ciekawa aplikacja.Są pewne ograniczenia związane z klawiszami Alt,Ctrl..(dostępny jest zestaw 2).Załóżmy,że ten układ działa tzn.klawiatura oraz uP podłączony przez RS do pc.Naciśnięcie klawisza powoduje odpowiednią reakcję w module np.DomowyKokpit,ale jak to wykorzystać w praktyce.Klawiaturę nie można zdekompletować i włożyć do kokpitu.Załóżmy,że ten pomysł można zrealizować.Pytanie jak to wykorzystać w budowie kokpitu.
Moje gratulacje EGHI.Ja też byłem bliski realizacji tego pomysłu,ale pojawił się MJoy i mnie uratował przed dalszymi próbami.
-
Klawiaturę nie można zdekompletować i włożyć do kokpitu
Chciałbym to wyjaśnić.Klawiaturę można zastąpić przyciskami tak jak to zrobił EGHI,które realizują naciśnięcie jednego klawisza.Aby zrealizować sterowanie pojedynczymi klawiszami to musimy wykonać montaż tych przycisków (tak jak to zrobił EGHI).Z klawiatury wykorzystamy tylko sterownik.Porównując ceny realizacji podobnego projektu (z wspomnianymi ograniczeniami) na MJoy oraz klawiaturze z dodatkowym uP (pomysł codeking)to nie widzę korzyści stosowania klawiatury,ale może się mylę.
-
Tak, z klawiatury wykorzystany byłby tylko sterownik (chyba, że ktoś chce również klawisze np. do FMC). Jeśli chodzi o wykorzystanie - jeśli działałoby to dobrze tzn. bez tego powtarzania naciśnięcia, to należy spojrzeć na to jak na przyciski w dowolnym joystick'u np. MJoy. A gdyby tak wtedy dorzucić płytkę enkoderów od MJoy'a ?
Koszty realizacji:
- MJoy to koszt 40-50 PLN.
- klawiatura (używka, można nawet znaleźć gdzieś w domu :) ) 10 PLN, elektronika 10-15 PLN, dochodzi jeszcze płytka i ewentualna przejściówka RS232<->USB, czyli koszt łączny pewnie w okolicach MJoy'a lub mniej
To jest tylko propozycja, trzeba zrobić układ testowy i zobaczyć czy to w ogóle da się dobrze i łatwo zrealizować.
PS. Wykorzystanie tego byłoby łatwiejsze w FS niż w Falconie. W FS mamy FSUIPC i SimConnect. Falconem można sterować "tylko" joystick'iem, klawiaturą i myszą. Więc w tym przypadku można by tylko emulować klawiaturę (btw. można to już robić w aktualnej wersji aplikacji DomowyKokpit).
-
(btw. można to już robić w aktualnej wersji aplikacji DomowyKokpit).
Jak zakończę mój CP to mam ochotę na testy.Test polegałby na dołączenie 3 MJoy i 2 joystików,czyli to z czym miałem problem w SV Mapper.Jeśli to wypali to jest nowa perspektywa zastosowania większej liczy MJoy w kokpicie.Ja to widzę jako uzupełnienie projektu Skalarki.Przy mojej koncepcji robienia niezależnych modułów to takie połączenie platformy głównej np.projekt Skalarki oraz pracujących autonomiczne MJoy byłoby korzystne.Warunek to soft codeking widzący wszystkie sterowniki.W obecnym rozwiązaniu mam platformę główną opartą na OC oraz 2 niezależnie pracujące MJoye.
-
Jak tam postępy w pracach ??
-
Prace w toku ;)
-
No liczę, że niebawem wszystko stanie się jasne ...
-
Witam,
chciałbym pochwalić się małym sukcesem związanym z zasilaniem kokpitu (elektroniki).Stosuję rozwiązania (karty) OpenCockpits.W początkowym etapie budowy kokpitu stosowałem podstawową kartę Master,która komunikuje się z PC przez LPT.Oprócz tej karty mam 3 karty Display.Wszystkie karty są zasilane z zewnętrznego zasilacza od starego PC.Dokupiłem ostatnio od OC kartę USB Epxpansion,która komunikuje się z PC przez USB i steruje kartą Master przez LPT.Kartą można zasilać przez USB z PC lub z zewnętrznego zasilacza.W rozwiązaniu OC pin1 (+5v) z gniazda USB jest połączony z pinem zasilania zewnętrznego +5V.Czyli napięcia +5V są połączone równolegle.Trochę długi wstęp,ale potrzebny aby zrozumieć mój problem.
Połączyłem nową kartę USB Expansion do PC oraz Master.Nowa karta była zasilana z PC przez USB a pozostałe z zewnętrznego zasilacza.System pracował poprawnie,ale miał jedną wadę.Jeśli wyłączyłem na moment zewnętrzny zasilacz to nie chciał się włączyć ponownie,tak jakby był blokowany napięciem z USB.Wyjęcie przewodów LPT oraz USB z karty powodowało,że można było włączyć zasilacz ponownie.Zgłosiłem problem do OC,ale stwierdzili,że może zasilacz zewnętrzny ma za mały prąd (co jest oczywiście nieprawdą).Zapytałem także czy mogę podłączyć równolegle do +5V (USB pin1) zewnętrzne napięcie +5V do karty USB Expansion.Nie otrzymałem odpowiedzi.
W związku z czym odciąłem zasilanie +5V wspomnianej karty od PC (3 przecięte ścieżki oraz 3 mostki na płycie) i podłączyłem napięcie zewnętrze.Teraz jest o.k.Zawiadomilem OC o moim rozwiązaniu problemu.Dodatkowa korzyść jest taka,że po wyłączeniu PC nie świecą 7-seg.LED z USB.Nie było to intensywne świecenie,ale widoczne.
-
Zapytałem także czy mogę podłączyć równolegle do +5V (USB pin1) zewnętrzne napięcie +5V do karty USB Expansion.Nie otrzymałem odpowiedzi.
Nie można. Urządzenia USB zasila się albo a PC albo z zewnętrznego zasilacza. "Albo" jest b.ważne
-
Nie można. Urządzenia USB zasila się albo a PC albo z zewnętrznego zasilacza. "Albo" jest b.ważne
Tak myślałem,dlatego zrobiłem modyfikację na płycie odcinając zasilanie karty od USB.Jeśli mam rację to OpenCockpits zrobiło poważny błąd projektowy w karcie USB Expansion,ponieważ na tej karcie +5V jest zwarte (tzn.to z PC przez USB pin1) oraz zewnętrze dołączone do złącza.Zanim zrobiłem modyfikację karty pomierzyłem prąd zasilający kartę z PC przez USB.Tak jak napisałem poprzednio karta ta jest połączona przez kabel LPT z kartą Master czyli oprócz masy GND są połączenia z wejściami,wyjściami elementów elektronicznych karty Master.Jeśli mamy podłączone 2 zasilania tzn.zewnętrzne zasila wszystko oprócz karty USB Expansion,która jest zasilana z PC to prąd z PC wynosi około 35mA.Jeśli wyłączymy zasilanie zewnętrzne to zwiększa wartość do 180mA.Próba ponownego włączenia zasilacza zewnętrznego w tych warunkach była skazana na niepowodzenie.Nie potrafię wyjaśnić tego zjawiska,ponieważ nie mam schematu zasilacza zewnętrznego (jest to zasilacz od starego PC),ale przypuszczam,że napięcie od PC przez elektronikę dostaje się na wyjście +5V zasilacza zewnętrznego i to powoduje jego blokadę.
Zjawisko opisałem i przesłałem do support OC.Na razie nie otrzymałem odpowiedzi.
Ważny wniosek dla nas.Budując platformę musimy przewidzieć możliwość podłączenia zewnętrznego zasilnia z możliwością rozłączania +5V z USB od PC.
Z ciekawości pytanie do Skalarki.Ja rozwiązałeś problem zasilania swojej platformy?
-
Z ciekawości pytanie do Skalarki.Ja rozwiązałeś problem zasilania swojej platformy?
To nie problem jako taki. W nowej wersji płytka zasilana jest z osobnego zasilacza napięciem 9-12V DC.
128 jednocześnie zapalonych LED-ów + 32 wyświetlacze 7-seg trochę prądu potrzebuje.
-
Witam po Świętach!
Ten filmik http://www.youtube.com/watch?v=J9KXv79AJgY (http://www.youtube.com/watch?v=J9KXv79AJgY) pokazuje działanie modułu napisanego przez codekinga a obsługującego mój projekt. Brawo dla tego gościa! Filmik pokazuje tylko interakcje pomiędzy płytką a softem a to oznacza że moja płytka i soft codekinga się dogadują, co było podstawą do dalszezj pracy nad softem. Teraz wszystko w rękach codekinga.
Pod kolejnymi linkami znajdziecie filmiki pokazujące działanie kilku nowych elementów projektu.
Tutaj http://www.youtube.com/watch?v=sFi5MS3gM0o (http://www.youtube.com/watch?v=sFi5MS3gM0o) pokazana jest obsługa encodera do zmiany ciśnienia w EFIS CS, działanie przycisków oraz działanie przełącznika TOGGLE.
Tutaj http://www.youtube.com/watch?v=T7jUowD1mqA (http://www.youtube.com/watch?v=T7jUowD1mqA) pokazane jest działanie FCU a raczej jego wyświetlaczy bo na resztę brakło czasu.
-
Witam,
moje gratulacje.Mam nadzieję,że także włączę się do testów platformy Skalarki oraz softu Codeking,ale dla Falcona.
-
Ponieważ jest sporo pytań dotyczących ceny płytek itp. wyjaśniam:
Płytki na razie nie będą dostępne w oficjalnej sprzedaży, dopóki cały projekt nie zostanie zakończony. Jednakże każdy kto chciałby wspomóc projekt może kupić wybraną płytkę po kosztach wytworzenia + elementy, zgadzając się jednocześnie na aktywną współpracę w testowaniu i tworzeniu oprogramowania - taki BETA TESTERS PROGRAM.
Dodam, że samodzielne zrobienie płytki ze względu na jej skomplikowanie w zasadzie nie jest możliwe (wiem bo próbowałem :002:)
Ponieważ nie chcę na forum uprawiać handlu, wszystkich zainteresowanych szczegółami proszę o kontakt na maila lub PW.
-
Jako "BETA TESTER PROGRAM" zainteresowanych gorąco namawiam. Koszt niewielki a pomoc w testach bezcenna :)
-
Witam serdecznie!
Żeby pokazać, że nie wypadłem sroce spod ogona, cytaty z tego forum. Miałem wtedy identycznego nicka, tylko chyba zaniedbałem się w pisaniu i musiałem rejestrować się na nowo.
http://www.il2forum.pl/index.php?topic=2200.msg38315#msg38315
http://www.il2forum.pl/index.php?topic=6950.msg93886#msg93886
Obecnie strona www.totom.su.pl znów nadaje, choć zawartość jest tam niestety archaiczna.
Obecnie mój kokpit mocno rozbudowany stoi i ma się dobrze w Kielcach.
(http://images6.fotosik.pl/340/87c1843e60d18736.jpg)
(http://images6.fotosik.pl/340/2602a8f7417f2e42.jpg)
(http://images6.fotosik.pl/340/b34fb08e70c89911.jpg)
(http://images49.fotosik.pl/112/97c7a7c79ed23256med.jpg)
(http://images44.fotosik.pl/229/853a524ff048970cmed.jpg) (http://www.fotosik.pl)
Oraz filmik http://rapidshare.com/files/171545133/film_kazka.wmv
Wspólnie z nowym właścicielem rozbudowujemy go systematycznie. Ja wracam "do interesu" po 2 latach przerwy. I widzę, że ta przerwa to był bardzo dobry pomysł. Jak zaczynałem z B737 nie było w Polsce żadnej elektroniki, programów. Nie było nic... więc teraz, kiedy widzę jaki postęp zrobiliście Panowie, to czapki z głów!
Krótko mówiąc zdecydowałem się na elektronikę od Marcina i w ten sposób zniknęło brakujące ogniwo mojego projektu A320.
Pomału przebijam się przez ten wątek. Gdyby ktoś chciał jakieś porady nt. B737 to co nieco jeszcze pamiętam. Ewentualny wjazd do kokpitu w Kielcach również nie jest problemem.
Przez okres "symulatorowego urlopu" udało mi się połączyć moje hobby - fotografowanie z lataniem GA. Ale jednak symulatory ciągną do siebie...
Powodzenia w budowaniu! I dopisać +1 do aktualnych budowniczych ;)
-
Witam Pioniera polskich budowniczych :001:
:karpik :karpik :karpik ;)
-
Odbiję temat w inną stronę, właśnie uruchomiłem lewy MFD. Mały teścik:
http://www.youtube.com/watch?v=8coNOp-UufI&feature=player_embedded
Pojechałem nieco z muzą :021: ale taką wybrało losowo, zostawiam więc. (miłośnikom Disco Polo polecam na wstępie wyciszyć :))
Jutro prawa strona.
Pozdrawiam!!
-
Witam ToTom,jestem pod wrażenie nie wiem co napisać.Te nasze próby tworzenia kokpitów przy Twoim projekcje wyglądają mizernie.Cieszę się,że będziemy mieli wsparcie tak doświadczonego "pitbuildera".
Moje gratulacje EGHI,dobra robota
pozdrawiam vito_zm
-
Troszkę off topic ale spodobało mi się related na youtube dla filmu skalarki... Domowy kokpit, skalarki projekt, domowy kisiel wiśniowy :banan - Niech żyje Youtube :karpik
PS EGHI wysłałem Ci zaproszenie do przyjaciół.
-
To moja wina bo nie dopisałem tagów i youtube sam mi wygenerował.
-
Postanowiłem wrócić po długiej przerwie do aplikacji codeking Domowy Kokpit.
Chciałbym nawiązać do mojego pytania i odpowiedzi na pw do codeking.Ponieważ temat jest ciekawy to umieściłem go na forum.
cytat codeking
..zacząłem pisać moduł do obsługi takich wyświetlaczy podłączonych do PC przez port LPT tak jak na tym schemacie - http://www.mikkila.org/fsbus/lcd/index_e.php Jest duża szansa, że moduł będzie gotowy jeszcze w tym tygodniu. Pokaże go gdy będzie działał tzn. sprawdzony zostanie u Zająca i np. u Ciebie jeśli będziesz miał wyświetlacze tak podłączone. Mógłbyś wtedy zacząć pisać konkretne skrypty do Falcon'a i tych wyświetlaczy..
W związku z tym cytatem mam pytanie.Czy wspomniany wyświetlacz (HD44780) będzie sterowany z programu Domowy Kokpit czy z innego modułu?
Jeśli będę chciał go testować (myślę o LPT oraz HD44780 ) w symulatorze Falcon to przy pomocy programu Domowy Kokpit ?
-
Czy wspomniany wyświetlacz (HD44780) będzie sterowany z programu Domowy Kokpit czy z innego modułu?
Jeśli będę chciał go testować (myślę o LPT oraz HD44780 ) w symulatorze Falcon to przy pomocy programu Domowy Kokpit ?
Tak, moduł powstaje do aplikacji DomowyKokpit. Pokazywałem kiedyś filmik na którym konfigurowałem taki wyświetlacz tzn. definiowałem na nim obszary znakowe. http://www.youtube.com/watch?v=GqCTjsbKHxo i http://www.youtube.com/watch?v=rBwnc9X80QQ Konfiguracja wyświetlaczy będzie inna ale obszary znakowe takie same i tak samo będą działały.
-
Witam,wykorzystałem stary prototyp do testów projektów Damosa to testowania LCD.
(http://img34.imageshack.us/img34/2272/lcddoforumh.th.jpg) (http://img34.imageshack.us/i/lcddoforumh.jpg/)
Pierwsze testy z programem LCD Smartie nieudane.Pytanie do kolegów jak ustawić setup w programie,aby wykonać prosty test.Czy jestem w stanie mając prosty wskaźnik np miernik napięcia lub LED (jako próbnik) stwierdzić czy LCD komunikuje się z pc przez LPT.
-
Te prostokąty oznaczają włączenie zasilania, ich brak oznacza zainicjowanie przez program do obsługi. Zobacz tutaj http://lcdsmartie.sourceforge.net/HDSetup.html
-
Problem był trywialny.Należało ustawić w biosie opcję LPT na EPP.Jako ciekawostka to karta Master z OC u mnie nie pracuje w tej opcji tylko w opcji normal.Dzięki za radę codeking,teraz mogę użyć Twojego modułu,ale to dopiero jutro.
-
Gdyby ktoś chciał jakieś porady nt. B737 to co nieco jeszcze pamiętam.
Możesz napisać jak zrealizowałeś od strony mechanicznej A/T ? Chodzi mi głównie o sterowanie, silnik, sprzężenie z dźwignią. Co się dzieje gdy jest włączone A/T a vPilot ruszy dźwignię ?
-
Możesz napisać jak zrealizowałeś od strony mechanicznej A/T ? Chodzi mi głównie o sterowanie, silnik, sprzężenie z dźwignią. Co się dzieje gdy jest włączone A/T a vPilot ruszy dźwignię ?
Zasada jest prosta. Generalnie dźwigniami rusza albo pilot albo A/T. Nigdy razem. Można to tak uprościć, choć w realu możliwe jest rozpięcie A/T przez "przesilenie" silnika (mam na myśli silnik dźwigni a nie samolotu) - czyli pchasz dźwignię mimo oporu silnika i powyżej pewnego punktu "przesilenia" A/T się rozłączy.
Mechanicznie - zastosowaliśmy serwa modelarskie. Dostępne są w różnej wielkości i mocy. Gdy nie są sterowane napięciem, chodzą luźno.
1. Początkowo stosowaliśmy słabe serwa. Wymagały one bardzo luźnego prowadzenia dźwigni - małych oporów. I to był problem podczas sterowania ręcznego, bo dźwignie nie zatrzymywały się na swoich pozycjach, tylko zjeżdżały albo do 0 albo do MAX w zależności, gdzie się je puściło. Rozwiązanie: użycie serw do podtrzymywania dźwigni w pozycji ustalonej przez pilota podczas sterowania ręcznego. Brzmi skomplikowanie ale działa. U Kazka jest właśnie to rozwiązanie.
2. Zastosowanie mocnych serw pozwoliło na takie opory na dźwigni, aby sterując ręcznie można było nie używać serw do ustalenia pozycji. Czyli po prostu w czasie sterowania ręcznego serwa nie są sterowane napięciem, poruszają się luźno. A w czasie pracy A/T serwa są na tyle mocne, że mogą bez problemów poruszyć dźwigniami.
Kto i kiedy porusza dźwigniami?
Rozważmy typowy lot:
W czasie kołowania A/T jest wyłączone. Przepustnica działa tylko manualnie.
Przed wjazdem na pas załączasz A/T. Przepustnica nadal działa manualnie.
Start - jedziesz manualnie do 50% i wciskasz TOGA.
W tym momencie wajcha powinna ustawić się sama a sterować położeniem powinna wyliczona w FMC wartość N1.
Potem w czasie lotu używasz różnych trybów. I tak:
LVL CHG:
- w czasie wznoszenia wajchą steruje wartość N1.
- w czasie zniżania wajcha powinna dojechać do 0 i potem przejść w sterowanie manualne - prędkość zniżania ustalasz ciągiem.
SPEED - tu wajchą steruje wartość ciągu - zawsze.
Podchodzisz do lądowania - po ustabilizowaniu możesz podchodzić na A/T. Przed przyziemieniem wciskasz A/T Disarm na TQ i to pozwala na manualne sterowanie ciągiem. Możesz też pstryknąć guziczkiem A/T na MCP i efekt będzie ten sam.
W momencie przyziemienia wajcha od spojlerów powinna pojechać do tyłu - oczywiście, jeśli była w pozycji "ARM". Ale podczas startu, kiedy zrobisz RTO to mimo, że wajcha nie jest na ARM to i tak powinna pojechać do tyłu.
Jak zrobić "przesilenie"?
Programowo - A/T podaje wyliczoną pozycję dźwigni na powiedzmy 100. Przeliczasz to na spodziewaną wartość na potencjometrze. Następnie porównujesz z odczytaną wartością z potencjometra. Jeśli przesilisz dźwignię czyli wartość na potencjometrze o np. 20% (lub jednostek, kwestia umowna) w jedną, lub drugą stronę, to do FSa można wysłać informacje na odpowiedni offset o wyłączeniu A/T.
Zastosowana elektronika to - FSBUS - "AD" do odczytu i "servo" do serw.
Mechanika - układ zębatek o odpowiednich przełożeniach i nic więcej. Czarów nie ma.
W realu ruch A/T wygląda tak:
http://www.youtube.com/watch?v=OEa7L5-_uTE&feature=related
http://www.youtube.com/watch?v=ciFgzsjwFmI&feature=related
W kokpicie u Kazka mamy bardzo podobnie.
PS. Często w kokpicie siada ktoś nieznający zasad A/T i siłuje się z dźwigniami. Serwa u Kazka są na tyle słabe a jednocześnie wytrzymałe, że pomimo 4 latek zabawy działają bez zastrzeżeń mimo takiego ich brutalnego traktowania. Zbyt mocne serwa w konkurencji z siłą na drążku mogą urwać przekładnie albo złamać rękę. W zależności co pęknie pierwsze ;)
-
Dzięki za obszerną odpowiedź. Nasuwają mi się kolejne pytania:
1. Czy w ten sposób A/T działa we wszystkich Boeingach ? Czy są różnice między modelami ?
2. Czy serwa są przerabiane tzn. usuwane jest ograniczenie ruchu tak by mogły wykonywać wiele obrotów ?
3. Indukcja napięcia przez silnik serwa. Serwa mają duże przełożenia więc ręczne obracanie mechanizmu powoduje duże obroty silnika, a ten z kolei indukuje prąd. Czy elektronika serwa ma zabezpieczenia przed tym czy może trzeba dodać własne ? A może to nie ma znaczenia ?
4. Dźwignie są sprzężone bezpośrednio z serwem czy są jakieś dodatkowe przekładnie ?
5. Jeśli serwo wytrzymało już 4 lata to jakie to serwo jest ? Chodzi mi o parametry bo serwo serwu nie równe, można kupić za 20,00 PLN i za 200,00 PLN.
6. Pytanie dodatkowe o przełącznik A/T Arm (widoczny na pierwszym filmiku). Gdzie można taki kupić ? Czy może to manualna robótka ?
-
No to po kolei:
1. Czy w ten sposób A/T działa we wszystkich Boeingach ? Czy są różnice między modelami ?
Szczerze mówiąc nie wiem. Z powodu ogromnych różnic pomiędzy kokpitami (w odróżnieniu od Airbusa) nie rozpracowywałem ani 757 ani 767. Ale jeśli jesteś zainteresowany, służę kompletem dokumentacji. Teraz również sporo jest do podglądnięcia na youtube. 5 lat temu takiej możliwości nie było.
2. Czy serwa są przerabiane tzn. usuwane jest ograniczenie ruchu tak by mogły wykonywać wiele obrotów ?
Z serw zdjęte są tylko oryginalne nakładki - popychacze a w ich miejsce nasuwana jest zębatka. Obracają się tyle, ile mogą fabrycznie czyli jakieś 200 stopni.
3. Indukcja napięcia przez silnik serwa. Serwa mają duże przełożenia więc ręczne obracanie mechanizmu powoduje duże obroty silnika, a ten z kolei indukuje prąd. Czy elektronika serwa ma zabezpieczenia przed tym czy może trzeba dodać własne ? A może to nie ma znaczenia ?
Powiem tak - elektronika to nie była moja działka. Więc albo to o czym piszesz ma w sobie płytka servo FSBUSa albo samo serwo. Faktem jest, że dla pełnego "bezpieczeństwa" ja miałem serwa wpięte na oddzielnej płytce COM i do tego był uruchomiony oddzielny FSBUS odpowiedzialny tylko za serwa. Bo w momencie ruszania dźwigniami generowały się losowe zdarzenia typu KEY, LED itp. Więc może występowało to, o czym piszesz.
4. Dźwignie są sprzężone bezpośrednio z serwem czy są jakieś dodatkowe przekładnie ?
Zębatka na serwie i sprzężona z zębatką na osi dźwigni. Kolejna zębatka był od potencjometru. I chyba tyle, szczegółów w tej chwili nie pamiętam.
Tu masz detaliczne fotki:
http://www.737ng.co.uk/symulatory.htm
Przykładowa:
(http://www.737ng.co.uk/symulatorytq13.jpg)
5. Jeśli serwo wytrzymało już 4 lata to jakie to serwo jest ? Chodzi mi o parametry bo serwo serwu nie równe, można kupić za 20,00 PLN i za 200,00 PLN.
Hmm, najtańsze (o ile pamiętam). Akurat mam przed sobą jedno (bo spaliłem przypadkowo podpinając odwrotnie zasilanie).
Made in Taiwan, GWS Servo, Mini STD, 3.4 kg-cm.
http://smittieshobbies.tripod.com/smittieshobbies/gws1.html
Teraz pewnie są inne i pewnie ceny niższe...
6. Pytanie dodatkowe o przełącznik A/T Arm (widoczny na pierwszym filmiku). Gdzie można taki kupić ? Czy może to manualna robótka ?
To na filmie to oryginał. W sklepie elektronicznym są pstryczki/elektryczki z podobnymi, takimi płaskimi dźwigienkami.
-
Vito,
znalazłem coś takiego:
http://cgi.ebay.com/Character-LCD-Module-Display-LCM-404-4004_W0QQitemZ190354915397QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2c52098045
Więcej znaków, niestety tylko 4 linie. Na DED odpada ale może PFL?
-
Wyświetlacz jest dobry zarówno do DED jak i PFL pod warunkiem,że mamy 4 linie.Zastanawiałem się nad problemem wyświetlania wspomnianych DED oraz PFL i doszedłem do wniosku,że łatwiej jest zrobić DED nawet stosując LCD 4x25.Cały czas mam na myśli wyświetlanie 4 linii.Komendy zmieniające informację na DED są wydawane poprzez wybór przycisku na ICP.Znamy kombinację klawiszy odpowiadającą przyciskowi oraz odpowiadający mu szablon obrazu (tekstu) na DED.Wystarczy zmienić trochę tekst usuwając np.spacje tak aby się zmieścić w 25 kolumnach.Wybór szablonu tekstu zależy od określonego przycisku,czyli wystarczy funkcja warunkowa typu IF ELSE.
Gorzej jest z PFL,ponieważ treść informacji na LCD jest zależna od alarmu (zdarzenia).Teraz widzę,że to można także rozwiązać.Jeśli znamy zależność pomiędzy wystąpieniem alarmu oraz treścią na PFL to możemy postąpić podobnie jak dla DED.
Reasumując lepiej mieć nadmiar kolumn w wyświetlaczu i przepisać treść linii do wiersza niż kombinować z programowaniem.Jeśli coś pomieszałem proszę o korektę.
-
Mam problem.Kupiłem kartę do sterowania silnikami serwo,ale nie wiem jakie serwo potrzebuję.Są dostępne analogowe i cyfrowe.
http://www.andare-ing.com/uploads//USBServos%20(english).pdf
Z instrukcji wynika,że potrzebuję R/C serwo motor z 3 wyprowadzeniami +5V,Data oraz GND.Czy mogę prosić o radę jaki kupić silnik.
-
vito,
na nasze potrzeby takie:
http://cgi.ebay.co.uk/6x-MYSTERY-9g-Mini-Micro-Servo-RC-plane-helicopter-Boat_W0QQitemZ270516127446QQcmdZViewItemQQptZUK_ToysGames_RadioControlled_JN?hash=item3efc0486d6
-
Witam,w końcu uruchomiłem tę kartę.Prosiłem o pomoc na forum OC,ale jej nie otrzymałem.W końcu przy pomocy znajomego z Hiszpanii napisałem skrypt pod SIOC i mogłem wykonać proste testy.Do testów użyłem prostego wskaźnika zrobionego z przerzutnika oraz LED.Jutro podłączę serwery.
(http://img94.imageshack.us/img94/5141/servoforum.th.jpg) (http://img94.imageshack.us/i/servoforum.jpg/)
Z drugą kartą USBLcd nadal mam problemy.
-
Witam,serwery już pracują.Teraz muszę trochę poczytać jak zrobić skrypt pod Falcona.Pozostaje dosyć poważny problem wykonania przekładni umożliwiający pełen obrót wskazówki o 360 stopni.Mam zamiar zrobić to przy pomocy 2 serwerów,jeszcze nie wiem jak,ale mam nadzieję,że problem zostanie rozwiązany.
(http://img9.imageshack.us/img9/9830/serwa.th.jpg) (http://img9.imageshack.us/i/serwa.jpg/)
-
Rozbierz górną przekładnie i będzie tam jedna z wypustką - trzeba ją usunąć, oraz zrobić małą podmianę - zamiast potencjometru 2 rezystory i serwo (serwomechanizm - serwery znam, ale takie komputerowe ;p ) będzie miał możliwość obrotu o 360 stopni.
Dokładny opis masz tutaj:
http://www.youtube.com/watch?v=bpO7XMXGzfw&NR=1
krok po kroku co i jak - powinno pasować do większości modelarskich serw (moje turnigy 9g tak przerabiałem) Pozdrawiam!
-
Dzięki za informację.Tak się zastanawiam jak to będzie działało.Widziałem podobne modyfikacji gdy przerabiano serwo na silnik obrotowy dla napędu pojazdów (robotyka),ale w tamtym przypadku usuwano elektronikę.Tutaj jest inaczej.Usunięto blokadę oraz potencjometr.Potencjometr ma za zadanie pamiętania pozycji czy kąta obrotu.Tak myślę,że tak zmodyfikowane serwo nie można skalibrować,czyli ustawić wartość zerową.
W moim zastosowaniu serwo ma wskazywać jakiś parametr lotu np.prędkość,temperaturę itp.i ma działać w przybliżeniu od 0 do 360 stopni,dlatego pomyślałem o dwóch serwach połączonych przekładnią,gdzie jedno działo w zakresie 0 180 a drugie 180 360.Nie jestem mechanikiem dlatego mam pewne problemy jak to zrobić.
-
Dzięki za informację.Tak się zastanawiam jak to będzie działało.Widziałem podobne modyfikacji gdy przerabiano serwo na silnik obrotowy dla napędu pojazdów (robotyka),ale w tamtym przypadku usuwano elektronikę.Tutaj jest inaczej.Usunięto blokadę oraz potencjometr.Potencjometr ma za zadanie pamiętania pozycji czy kąta obrotu.Tak myślę,że tak zmodyfikowane serwo nie można skalibrować,czyli ustawić wartość zerową.
W moim zastosowaniu serwo ma wskazywać jakiś parametr lotu np.prędkość,temperaturę itp.i ma działać w przybliżeniu od 0 do 360 stopni,dlatego pomyślałem o dwóch serwach połączonych przekładnią,gdzie jedno działo w zakresie 0 180 a drugie 180 360.Nie jestem mechanikiem dlatego mam pewne problemy jak to zrobić.
Zastanawiam się dlaczego chcesz konia przerobić na wielbłąda i po co. Jeśli chcesz budować wszelakiego rodaju wskaźniki mechaniczne do tego celu służą silniki krokowe a nie serwa. Serwa stosue się tylko tam, gdzie nie potrzebny jest pełen obrót, do wszystkich innych zastosowań tylko silniki krokowe.
Z OC dostępna jest również płytka do sterowania stepper motorami, stosując ją omijasz wszystkie problemy o których piszesz powyżej.
Tutaj znajdzisz sporo opisów i instrukcji jak zrobić dowolny wskaźnik http://www.mikesflightdeck.com/mfdbooks.htm
-
Serwo jest wg. mnie lepsze do wskaźników od silników krokowych, wystarczy dodać przekładnie aby te 180 stopni serwa zamienić na 360 stopni. Przewaga jest taka, że jest prostsze sterowanie. Aby wykorzystać silnik krokowy przydałby się jeszcze dodatkowo potencjometr lub enkoder do liczenia kroków, bo czasem silnik/sterownik może "zgubić" krok i wtedy wskaźnik będzie źle pokazywał. Ale wiadomo, dla jednego dobre jest serwo dla drugiego silnik krokowy, obydwa rozwiązania są dobre ale wg. mnie do innych celów.
Nie rozumiem jednak tego, po co vito_zm chcesz kombinować z dwoma serwami na jeden wskaźnik ? Łatwiej będzie dodać przekładnię zwiększającą zakres ruchu.
-
Witam,
dlaczego serwo?Powód jest jeden nie wiem jak napisać skrypt dla Falcona dla silnika krokowego.Znalazłem na viperpits rozwiązanie jak zrobić wskaźnik z pełnym obrotem
http://www.viperpits.org/smf/index.php?topic=1581.105
na stronie 8 jest to pokazane.Na wcześniejszych stronach 6 oraz 7 są także informacje.Chcę zrobić testy przy pomocy autora tego pomysłu.Prosiłem go o skrypt obiecał,że przyśle..Są na forum OpenCockpits przykłady skryptów dla silników krokowych,ale dla FS.
Problem dla takich jak ja polega na tym,że sterujemy kokpity (mam na myśli Falcona) stosując niewłaściwe platformy.
Jeśli stosuję karty OC jestem skazany na program FAST.
Jeśli stosuję karty skalarki potrzebuję program Domowy Kokpit,ale z możliwością przechwytywania danych z share memory.
Jeśli stosuję platformy z viperpits to muszę mieć odpowiedni program.
Logika mówi,aby przejść na jedną z platform z viperpits np.PHCC oraz odpowiednie oprogramowanie i mieć problem z głowy.Ja mam zamiar przejść stopniowo na platformę skalarki.Jest to możliwe tylko dlatego,że codeking napisał odpowiedni program.Sterowanie wskaźnikami analogowymi za pomocą silniczków serwo lub krokowych chcę zrobić za pomocą kart OC.
Obecnie na viperpits jest sprzedawane rozwiązanie zrobione na aircore Simco.Na stronie 4 jest to pokazane
http://www.viperpits.org/smf/index.php?topic=4287.45
Facet zrobił sterownik pod te silniczki,inny zrobił opisy i to sprzedają o ile się nie mylę za 350 EUR,do tego trzeba dokupić 4 aircore.Jest to dosyć drogie rozwiązanie.Mam nadzieję,że przy pomocy EGHI zrobimy tańszy projekt.
Jeśli znajdę sposób na napisanie skryptu pod FAST dla silnik krokowego to będę ten wariant testował.Jeśli ktoś ma jakiś pomysł to chętnie skorzystam.Bardziej się znam na elektronice niż na mechanice.
-
Mam nadzieję,że przy pomocy EGHI zrobimy tańszy projekt.
Damy rade, nie zajmuje się jeszcze tym tematem ale wstępnie wiem jak to zrobić. Są dwa sposoby, pierwszy to dwa servo na jeden wskaźnik. Na RH (prawej konsoli) mamy 4 sztuki- Oil, Nozzle, Rpm i Ftit czyli potrzeba 8 servo. Nie pamiętam ile można podłączyć do karty OC, chyba 6? Jeśli tak to trzeba użyć dwie karty.
Drugi sposób to przekładnia zębata. Potrzebne są dwa koła zębate, większe montujemy na servo, mniejsze na osi wskaźnika. Oczywiście trzeba dobrać odpowiednie przełożenie, tak żeby uzyskać 360* obrót.
Z tych dwóch opcji druga jest lepsza. Pozornie trudniejsza ze względów na elementy mechaniczne, ale przy użyciu dwóch servo i tak trzeba zrobić przekładnie, nie unikniemy więc zabawy z zębatkami. Jeszcze jeden argument przemawiający za opcją nr.2 to ilość servo. Jeden wskaźnik-jeden servo.
Na razie to jest teoria, inne pomysły mile widziane. Kupie jakieś servo i zobaczymy na ile precyzyjnie da się taki mechanizm zbudować.
Tym czasem, nieskromnie pochwale się tym:
http://img709.imageshack.us/img709/4209/p1050622.jpg
http://img695.imageshack.us/img695/3663/p1050614.jpg
Czuć jeszcze zapach farby :001:. Materiał to blacha aluminiowa 0,5 mm, bardzo łatwo się obrabia.
Pozdrawiam.
-
Pięknie wykonane, moje gratulacje.Ja też myślę,że damy radę z wykonaniem wskaźników.
-
Co do serw - zlikwidowanie potencjometru sprawi że, będzie się on kręcił w koło, tak jak przewidyjesz - jedynie jakiś enkoder zostaje wtedy aby ustalić położenie, ale to troche zabawy by chyba było. Czyli najprościej przełożenie 2:1 z serwa i już.
Super budujecie te kokpity :) Ja sobie chciałbym zmontować do ka-50 panelki - nie cały kokpit - nie mam miejsca, pieniędzy i czasu, ale mały panelek z ułatwieniami - czemu nie - szybciej by sie grało niż myszą klikając, no i efekt... :003:.
http://forums.eagle.ru/showthread.php?t=48368
http://forums.eagle.ru/showthread.php?t=32054
NIe wygląda to z daleka jakoś kosmicznie skomplikowanie, ale jakoś nie czuję się na siłach to wszystko ustawiać i kombinować... Ale jak mnie już najdzie zapewne poproszę o solidną pomoc :banan
-
jedynie jakiś enkoder zostaje wtedy aby ustalić położenie, ale to troche zabawy by chyba było.
Musi być potencjomert, kontroler odczytuje położenie z sygnału analogowego. Enkoder to nic innego, jak przełącznik obrotowy. Nie ma jakiegoś zakresu wartości, jeśli nim kręcisz daje impuls zawsze taki sam, równie dobrze można przyciskać przycisk(szybko).
Zastanawiam się nad zastosowanie innego potencjometru i likwidacji ogranicznika w mechanizmie. Zakładam, że silnik kręci zgodnie z zakresem rezystancji potencjometru. Tutaj może pojawić się kolejny problem- zakres ruchu takiego potencjometru. Jeśli ten w servo ma 2k i 180* obrót, trzeba poszukać taki sam ale z 360*.
Będzie servo, będą doświadczenia ( pewnie kilka wyląduje w koszu :004:)
-
Też o tym pomyślałem.Czekam na skrypt.Program który testuję ma małe możliwości manewru.Podoba mi się karta z OC,jest bardzo mała,ale funkcjonalna i najważniejsze,że działa.Silnik krokowy byłby idealny.Zapytam jeszcze znajomego,dlaczego zastosował serwo zamiast silnika krokowego.
-
Uzupełnienie ostatniego post.
Dane oraz aplikacja dla silnika krokowego oraz karty USBSteeper card są pokazane na stronie
http://www.opencockpits.com/modules.php?name=Content2&pa=showpage&pid=53
Główne cech to:
CONTROLLER RECEIVES SIGNALS FROM 3 POSITION SENSORS FOR CALIBRATION PURPOSES
CARD RECEIVES POSITION (0-359 DEGREES) AND SPEED INFORMATION AND CALCULATIONS ARE MADE AUTOMATICALLY.
MOTORS FROM OLD PRINTERS, FLOPPY DISCS READERS, ETC. CAN BE USED.
Jedyny problem to umiejętność napisania skryptu w SIOC przy wykorzystaniu FAST.
-
Jest postęp w testach z moimi serwami.Udało się zrobić skrypt,który steruje RPM w Falconie przy pomocy serwa.Pomoc otrzymałem z viperpits.Problem polega na tym,że jest dużo przykładów,ale pisanych pod FSUIPC dla FS.Nie wiedziałem jak powiązać SIOC z FAST,gdzie FAST jest w jakimś sensie odpowiednikiem FSUIPC.
Ponieważ niektóre skale są nieliniowe np.dla PRM to trzeba będzie dobrać różne współczynniki. Serwo ma zakres od 1 do 1023 a RPM od 0 do 110.Na skali wyświetlacza 0 do 70% mocy silnika zajmuje około 180 stopni a pozostałe 40% około 160 stopni (w przybliżeniu).
Myślę,że koledzy stosujący wskaźniki wskazówkowe będą mogli coś doradzić.
-
Vito, jak dobrze wiesz w moim projekcie potrzebuje zmotoryzować co najmniej 13 wskaźników wraz z SZH.
Czy tworzenie takiego skryptu jest łatwe czy skomplikowane i czasochłonne (moje pytanie odnosi się do pojedynczego przyrządu np wysokościomierza) ??
-
Dopiero próbuję rozeznać problem.Tak jak wspomniałem jest dużo przykładów skryptów dla FS pisanych pod FSUIPC.Ja mam Falcona i w tym przypadku brak przykładów.Na początek musisz zdecydować jaki hardware oraz soft będziesz stosował do swojego symulatora.Następnie należy poszukać przykłady np.skrypty pod to rozwiązanie.
-
vito,
PHCC Test Tool z tej strony http://www.assembla.com/wiki/show/lightningstools
To jest to, czego nam brakuje.
-
Test your PHCC cockpit interface hardware.
Masz rację,ale aby stosować to narzędzie to trzeba kupić platformę PHCC oraz kartę np.servo.Obecnie większość na viperpits stouje PHCC.
Przyjrzałem się skali na wskaźniku RPM w Falconie.Jest nieliniowa.Od 70% do 110% zajmuje 180 stopni i jest to moc podczas lotu.Od 0 do 70% to będzie moc przy rozruchu silnika.Ten przykład,który dostałem jest raczej poglądowy.Wychyla wskazówkę w zakresie około 45 stopni co odpowiada zmianie mocy od 70 d0 95%.
Jeśli skala jest liniowa to można to rozwiązać,jeśli nie to trzeba znaleźć wyrażenie arytmetyczne,które dla poszczególnych zakresów mocy zamienia moc na odpowienie odchylenie wskazówki.Ciekawe jak to rozwiązali koledzy od FS?
-
vito,
PHCC Test Tool z tej strony http://www.assembla.com/wiki/show/lightningstools
To jest to, czego nam brakuje.
Zdrajca :006:
-
Jeśli skala jest liniowa to można to rozwiązać,jeśli nie to trzeba znaleźć wyrażenie arytmetyczne,które dla poszczególnych zakresów mocy zamienia moc na odpowienie odchylenie wskazówki.Ciekawe jak to rozwiązali koledzy od FS?
Logarytm?
Trzeba zastosować funkcję logarytminczą a jej wynik przekazać do modułu wyjściowego.
http://www.math.edu.pl/narzedzia.php?opcja=wykres-funkcji (http://www.math.edu.pl/narzedzia.php?opcja=wykres-funkcji)
-
Zdrajca :006:
Ja tylko sugeruj, że takie narzędzie bardzo jest pomocne :004:
Tak przy okazji, do czego podłączysz silniki krokowe? Jakiś dodatkowy moduł? Może zrobisz coś pod servo? :121:
-
Pytanie do Vito lub EGHI. Ile silników krokowych potrzeba użyć w kokpicie FALCON-a żeby wsyterować wszystkie wskaźniki?
Tak przy okazji, do czego podłączysz silniki krokowe? Jakiś dodatkowy moduł? Może zrobisz coś pod servo? :121:
Właśnie robię rozszerzenie do silników krokowych.
-
Cztery sztuki na początek wystarczą. Pomijam wskaźniki na centralnej konsoli bo łatwiej to zrobić na LCD, ale kolejne cztery można wykorzystać. W sumie 8 :)
Jeśli już mowa o silnikach krokowych to trzeba poszukać podobne do tych, które tutaj facet zastosował:
http://www.viperpits.org/smf/index.php?topic=4287.45
Problemem może być soft. Chyba, że codeking podejmie wyzwanie :)
-
Jak będzie co obsłużyć (sprzęt) to będzie i moduł do DK.
-
No to zrobię rozszerzenie z możliwością podłączenia 8 stepper-motorów
-
To jest bardzo dobra wiadomość.Jeżeli uda się zrobić moduł do obsługi silników....to byłoby super.Oczywiście zależy to od Skalarki oraz Codeking.Co silników to są moduły wyspecjalizowane do serw oraz silników krokowych.Najlepsze byłyby silniczki aircore Simco.Są droższe,ale maja dużo zalet.
http://www.simcoltd.com/specialty-oem/micro-air-core/
Opencockpits ma karty (bardzo małe) podłączane do USB,obsługujące dwa pierwsze typy silników,nie mają rozwiązania dla aircore.Jeśli uda się zrobić taki moduł oraz program to będzie to bardzo konkurencyjny projekt.
Ponieważ kupiłem kartę dla serwo to będę temat drążył,ale wyniki mogą się przydać dla innych rozwiązań.
-
To jest bardzo dobra wiadomość.Jeżeli uda się zrobić moduł do obsługi silników....to byłoby super.Oczywiście zależy to od Skalarki oraz Codeking.Co silników to są moduły wyspecjalizowane do serw oraz silników krokowych.Najlepsze byłyby silniczki aircore Simco.Są droższe,ale maja dużo zalet.
http://www.simcoltd.com/specialty-oem/micro-air-core/
Opencockpits ma karty (bardzo małe) podłączane do USB,obsługujące dwa pierwsze typy silników,nie mają rozwiązania dla aircore.Jeśli uda się zrobić taki moduł oraz program to będzie to bardzo konkurencyjny projekt.
Ponieważ kupiłem kartę dla serwo to będę temat drążył,ale wyniki mogą się przydać dla innych rozwiązań.
Ponieważ micro-air-core to silniki typu "bipolar", do ich sterowania jest potrzebny inny układ wykonawczy niż do silników "unipolar". Więc trzeba by zaprojektować 2 rodzaje płytek do sterowania odpowiednich silników. Tylko które byłyby dla Was bardziej przydatne. Z punktu widzenia sterowania programowego nie ma to żadnej różnicy.
Ale znowu micro-air-core są chyba trudno dostępne, na szybko nie znalazłem żadnej strony internetowej, która je sprzedaje.
Jeśli chodzi o serwo, to jeśli będzie taka potrzeba to rozszerzenie też powstanie, nie jest to żaden problem.
-
Przyznam się szczerze,że nie mam pojęcia o silnikach.Tak jak wspomniałeś silniki krokowe są prawdopodobnie najlepsze do sterowania wskaźnikami.
Ale znowu micro-air-core są chyba trudno dostępne
To jest bardzo ważny argument.Myślę,że w tym temacie powinni zabrać głos ci co już stosują silniczki w swoich kokpitach.Może ToTom coś doradzi.
-
vito,
zrobiłem wstępny projekt tarczy wskaźników. Skala raczej jest ok, trzeba popracować jeszcze nad odpowiednim rozmieszczeniem. Trzy formaty - Corel, PDF i JPG jeśli ktoś jest zainteresowany.
(http://img682.imageshack.us/img682/117/engag1.th.jpg) (http://img682.imageshack.us/i/engag1.jpg/) (http://img693.imageshack.us/img693/2532/enginegauges2.th.jpg) (http://img693.imageshack.us/i/enginegauges2.jpg/)
No to zrobię rozszerzenie z możliwością podłączenia 8 stepper-motorów
Jeśli się uda, można próbować tak to sterować.
-
Tam jest błąd :008:
Tutaj poprawiony:
(http://img130.imageshack.us/img130/117/engag1.th.jpg) (http://img130.imageshack.us/i/engag1.jpg/)
-
Świetna robota EGHI.Musimy coś doradzić Skalarki serwo czy krokowy,co o tym myślisz?
-
Chciałbym uzupełnić ostatni post dotyczący wyboru silnika lub raczej modułu do jego sterowania.Z tego co napisał Skalarki nie ma problemu z hardware.Ponieważ Codeking ma napisać odpowiedni moduł programowy to jego zdanie ma decydujący głos.Z tego co doczytałem na forum to silniki krokowe mają możliwość kontroli stanu początkowego,dokłanie nie wie na czym to polega.Wskaźniki można realizować zarówno na serwach jak i na silnikach krokowych.Problem czy Codeking potrafi to oprogramować.
-
vito,
mamy servo, Ty masz kartę OC, skrypt też już prawie opanowany. Proponuję trzymać się planu, jak Skalarki zrobi sterowanie silnikami będzie można zastąpić servo. Do tego potrzebny będzie też soft, najlepiej coś na wzór zakładki servo w Test Tool o którym wspomniałem kilka postów wyżej. Jeśli będzie potrzebne przekładnia, to też już robię.
Tarcze mogę uznać za 98% gotowe, możliwe kosmetyczne poprawki. W kokpicie wygląda to tak:
(http://img189.imageshack.us/img189/8560/p1030638.th.jpg) (http://img189.imageshack.us/i/p1030638.jpg/)
Mogą też służyć jako atrapa.
-
Z tego co doczytałem na forum to silniki krokowe mają możliwość kontroli stanu początkowego,dokłanie nie wie na czym to polega.Wskaźniki można realizować zarówno na serwach jak i na silnikach krokowych.Problem czy Codeking potrafi to oprogramować.
Silnik sam w sobie to nie ale dodaje się do silnika bramkę fotooptyczną, która wykrywa obrót osi i w ten sposób wyznacza się punkt "0". Jednak w przypadku wskaźników kokpitowqych raczej nie będzie to potrzebne ponieważ wskaźniki można programowo zerować przed wyłączeniem programu sterującego kokpit a w przypadku np wysokościomierza (on się nie zeruje) wystarczy zapisać jego położenie a dokładniej ile kroków zrobił od poprzedniego załączenia.
Przewaga steppera nad servo jest taka że położenie osi można wyliczyć.
Jak znam codekinga i jego soft to spokojnie razem damy radę.
-
EGHI
Proponuję trzymać się planu, jak Skalarki zrobi sterowanie silnikami będzie można zastąpić serwo. Do tego potrzebny
Tak zrobię.Muszę zrobić skrypty pod OC i FAST.Serwo na krokowy zawsze możemy wymienić.Teraz mam wzorce będzie łatwiej.Przy okazji gratulacje wyglądają tak jak RedDoga.
Jak znam codekinga i jego soft to spokojnie razem damy radę.
To jest optymistyczne.Wiem,że teraz przechodzi się na wyświetlacze LCD,ale w wojskowych samolotach niektóre wskaźniki trzeba zrobić w tradycyjny sposób dlatego myślę,że nowy moduł zwiększy atrakcyjność Twojego rozwiązania.
-
Wykonałem kolejne testy z moim serwo i wyniki są zadawalające.Serwo kupiłem pod linkiem
http://www.modelmotor.pl/category/serwomechanizmy-serwa-analogowe-serwa-tower-pro/2
Jest to SG 91R i kosztuje 19.50 PLN.
Skrypt,który otrzymałem działa poprawnie.Testowałem serwo w pomiarze RPM w Falconie podczas lotu i zapomniałem o ograniczeniach mocy silnika(zakreskowany obszar).Dzisiaj wykonałem testy z ramp start oraz podczas lotu i teraz mam pełny zakres wychylenia wskazówki serwera.Jest to pokazane na szkicu.Jak widać zakres mocy silnika od 0 do 95% odpowiada wychyleniu kątowemu około 160 stopni.Teraz trzeba dobrać odpowiednią przekładnię tak aby otrzymać zakres od 0 do około 340 stopni.Myślę,że jest to do zrobienia.
(http://img38.imageshack.us/img38/2784/servo.th.jpg) (http://img38.imageshack.us/i/servo.jpg/)
-
A może by tak gotowiec...http://www.sklep.pilots.pl/product_info.php/products_id/542 :)
-
A może by tak gotowiec...http://www.sklep.pilots.pl/product_info.php/products_id/542 :)
Fajnie wygląda, poczekajmy na cenę i co tam będzie działać.
vito,
coś dla nas:
http://www.zebatki.com.pl/index.php?zadanie=glowna
-
Robię testy oraz poprawiam skrypt pod serwo.Z skryptem był problem,ponieważ na forum OC są przykłady ale pod FS,nie ma przykładu dla Falcona.Robiąc testy natrafiłem na problem związany z silnikiem serwo.Zakres pracy tego silnika jest od 0 do 1023 w umownej skali.W obu moich silnikach jest problem na początku zakresu tzn. od 0 do 150 na tej umownej skali.Problem polega na tym,że silnik się grzeje i nie chce się obracać.Pomierzyłem prąd i okazało się,że jest bardzo duży od 160 do 100mA.Dla pozostałego zakresu od 150 do 1023 wynosi 8mA.To by wskazywało na jakąś blokadę czy coś podobnego.Nie mam odwagi zdemontować serwa,ponieważ jestem kiepskim mechanikiem.Pozostaje kupić nowe i je sprawdzić.
-
Czy po włączeniu całego układu z serwami, serwa wracają do pozycji wyjściowych (jeśli były lekko "przekręcone") ? Może to jest problem, brak zerowania i w początkowym zakresie serwo dostaje sygnał, żeby kręciło się w stronę w którą już nie może bo jest zablokowane. To jest tylko moje przypuszczenie, nie znam płytki OC a serwa używałem tylko w modelu RC.
-
To jest ciekawe co piszesz.Co zaobserwowałem.Serwo niepodłączone do napięcia można poruszać mechanicznie w zakresie około 160 stopni.Mam program z OC do testowania serw.W tym programie mogę suwakiem (programowym) lub wpisując do okienka wartość (liczbę)sterować serwem.Zakres przesuwu ramienia zależy od wpisanej liczby lub zakresu przesuwu suwaka.Mogę robić to ze skokiem co 1 w zakresie od 0 do 1023 lub płynnie.Ten program daje duże możliwości sterowania.
Po podłączeniu serwa do karty oraz ustawieniu warości na 0 serwo jest w skrajnej lewej pozycji i prąd nie płynie.Jeśli będę przesuwał suwak zwiększając zakres do 150 to serwo zaczyna buczeć tak jakby chciało poruszać się w przeciwnym kierunku,grzeje się i prąd zwiększa się do 260mA.Prąd stopniowo maleje i w końcu przy wartości 150 osiąga 8mA.
Działając suwakiem w przeciwnym kierunku mogę przesunąc ramię do pozycji zerowej.Najlepiej pokaże to na zdjęciu
(http://img51.imageshack.us/img51/7923/testerservo.th.jpg) (http://img51.imageshack.us/i/testerservo.jpg/)
Zastanawiam się gdzie jest błąd.Program testujący wydaje się dobry,karta OC powinna być dobra,serwo może jest uszkodzone,ale dlaczego dwie sztuki.
Co mogę zrobić:zaprojektować tester do sprawdzania serw,kupić inny typ serwa,rozebrać serwo i sprawdzić mechanikę.Może ktoś ma pomysł?
-
Jeśli to wygląda na próbę ruszania się w złym kierunku to może serwa są niekompatybilne z płytką OC. Dziwne, ale może mają za mały zakres ruchu.
-
Chyba masz rację codeking.W opisie kart USBServo piszą
THIS CARD MANAGES UP TO 6 SERVOMOTORS WITH 10 BITS OF RESOLUTION (0-1023 POSITIONS)
THIS CARD IS PERFECT TO BUILD ANALOGUE GAUGES WITH LIMITED AND SMOOTH MOVEMENTSES DUE TO ITS 10 BITS RESOLUTION.
ANY TYPE OF COMMERCIAL SERVO MOTOR CAN BE CONNECTED TO THIS CARD.
Jak widać nie jest to do końca prawda.Jeśli przesuwam suwak w lewo to przy warości 150 serwo osiąga skrajną pozycję (blokada).Z teorii wynika,że szerokość impulsów decyduje o położeniu serwa.Przykładowo szerość impulsu 1,5 ms odpowiada pozycji 90 stopni 1.25 ms 0 stopni a 1.75ms odpowiada 180 stopni wychylenia ramienia serwa.Jeśli szerokość wysyłanych z karty OC impulsów nie odpowiada zaprogramowanym wartościom w serwerze to mamy konflikt.Co można zrobić:
-dopasować serwo do karty OC
-programowo ograniczyć zakres serwa.
W tym ostatnim przypadku mamy 2 sytuacje.Ograniczenie od początku skali lub od końca.
Dla ograniczenia od początku skali mam stałą warość(150) dla zakresu od 0 do 150 co odpowiada dla RPM od 0 do 17% .Skala dla tego zakresu jest "martwa".
Dla ograniczenia od końca skali warości dla RPM od 0 są bardzo dokładne,ale dla większych wartości mocy powyżej 70% jest zmniejszony zakres przesuwu ramienia serwa.
Nie wiem czy dokładnie to opisałem.Robię różne skrypty i je testuję,ale zawsze jest to kompromis.Pytanie do codeking jako programisty.Co wybrać?
Gdyby nie to ograniczenie na początku skali to zależność wychylenia ramienia serwa w pełnym zakresie 0 do 1023 można opisać równaniem
ServoRPM = 9.3*RPM gdzie RPM zmienia się od 0 do 110%.
Ja to zrobiłem w ten sposób
dla ograniczenia z początku skali
L0 = 9.3*RPM
IF L0 <150
ServoRPM = 150
ELSE
ServoRPM = L0
dla ograniczenia a końca skali
L0 = 9.3*RPM
L1 = L0 + 150
IF L1 > 1023
ServoRPM =1023
ELSE
ServoRPM = L1
Czy można zrobić to lepiej?
-
Jeśli po 70% wychylenia mają być mniejsze to lepiej robić to na dwa równania, inne dla RPM < 70% i inne dla RPM >= 70%. Po prostu w jednym dasz inny współczynnik (teraz 9.3). Musisz dobrać je doświadczalnie, jeśli masz wydrukowaną tarczę z prawidłową skalą dla RPM to po prostu trzeba się pobawić.
A co do tych serw, na szybko przeszukałem forum OC i wyszyły ciekawe rzeczy, zobacz te tematy:
- http://www.opencockpits.com/modules.php?op=modload&name=Forums&file=viewtopic&topic=4991&forum=13
- http://www.opencockpits.com/modules.php?op=modload&name=Forums&file=viewtopic&topic=4991&forum=13
W jednym z nich zasugerowano serwo http://www.emodel.pl/hitec-serwo-hs311-p-186.html (działa w zakresie od 20).
-
Zrobiłem coś takiego i to działa,ale jest cofnięcie wskazówki przy RPM=50 co jest logiczne.Trzeba z krzywej o dwóch kątach nachylenia przejść na parabolę.
L0 = 9.74*RPM
L1 = 9.12*RPM
IF RPM < 50
ServoRPM = L1 + 155
ELSE
ServoRPM = L0
Pozostaje jeszcze szukanie odpowiedniego serwa.HS-311 jest 2 razy większe od SG-90R.Jeśli EGHI wyrobi z wymiarami to można pomyśleć o testach.
-
Jeśli EGHI wyrobi z wymiarami to można pomyśleć o testach.
HS-311 są ogromne, ale sprawdzę czy zmieszczą się. Zrobiłem prototyp pod połowę mniejsze, może być ciężko.
Tak wygląda z najmniejszymi:
(http://img12.imageshack.us/img12/6493/dsc00291cj.th.jpg) (http://img12.imageshack.us/i/dsc00291cj.jpg/)
Te mają 20/11mm, HS-311 około 20/40mm.
Myślę, że servo nie ma tutaj większego znaczenia, ważne żeby były Typ R/C. Problem leży w odpowiednim dobraniu zakresu ruchu servo.
Może należy zmniejszyć zakres ruchu? Po co wykręcać na max w lewo i prawo? Przecież robię przekładnie i z np. 150* też można zrobić 360*, kwestia odpowiedniego przełożenia. Sprawdź, czy jak zmniejszysz skale servo nadal się grzeje?
-
Jeśli zmniejszę skalę o około 150 z 1023 to jest o.k.Problem w tym,czy wytypowane zębatki pokryją zakres np.340 stopni.
-
vito,
możesz zrobić rysunek z zmniejszoną skalą? Sprawdzę jak to się ma do przełożenia które mamy zamiar zastosować. Może nie trzeba dużo zmniejszać by servo zaczęło działać poprawnie?
-
W końcu rozwiązałem problem skalowania wskaźnika sterowanego serwem.Zrobiłem to przy pomocy niezawodnego kolegi codeking,który podpowiedział jak ułożyć równania realizujące ten projekt.
Przystępując do projektu nie miałem pojęcia jak działa serwo i jak zrobić skrypt do wskaźnika np.RPM dla Falcona.
1.Etap pierwszy to znalezienie sposobu sterowania serwem w relacji SIOC (program OpenCockpits),FAST (program do komunikacji Falcon SIOC) oraz serwo podpięte do karty USBServo.Ten etap był najtrudniejszy,ponieważ w dokumentacji OC są przykłady ale dotyczące FS.Na forum OC brak informacji.W końcu przez prywatny kontakt z forum viperpits uzyskałem informację jak zrealizować sterowanie Falcona w relacji SIOC,FAST.
2.Etap drugi to testowanie serwa przy pomocy programu testującego.Program jest niedostępny na stronie OC.Dostałem go od członka forum OC w momencie gdy realizowałem etap trzeci i miałem problemy z serwem.
Etap drugi polega na tym,że zmieniamy sterowanie serwem manualnie zadając wartość z zakresu od 0 do 1023 i obserwujemy wychylenie "wskazówki serwa".Karta OC umożliwia sterowanie serwa z rozdzielczością 10 bitów co odpowiada zakresowi 1 do 1023.Badając serwo zauważyłem,że działa wadliwie w zakresie 1 do 155.Objawiało się to tym,że wzrastał prąd z 8mA do 200 mA,serwo się grzało oraz hałasowało.Sterując serwo od warości większych do mniejszych przy zakresie 120 serwo przestało się obracać.
W etapie drugim poznałem wady tego typu serwa.
3.W etapie trzecim mojego projektu znając jego wady ułożyłem przy pomocy codeking równania realizujące sterowanie.
Założenia były następujące:
-określenie rozmiaru zakresu z uwzględnieniem wadliwego 1 do 155
-podział zakresu 868 na dwa zakresy tak aby rozszerzyć jeden kosztem drugiego,punkt podziału to 70% RPM
Po uwzględnieniu tych założeń można było obliczyć współczynniki dla obu zakresów i ułożyć odpowiednie równania.
4.W etapie 4 mając wyliczone dla poszczególnych warości RPM odpowiadające im wartości zakresu mogę to sprawdzić w relacji program testujący,serwo, wyliczenia i wykonać skalowanie.
Na załączonym wykresie jest to pokazane.Ten rysunek zrobiłem dla punktu podziału 40% RPM.
5.W etapie 5 trzeba napisać skrypt i wykonać skalowanie.Skalowanie wykonujemy na podstawie wskazań wskaźnika RPM w Falconie.
6.W tym etapie porównujemy skalowania z punktu 4 oraz 5 i wykonujemy korekcję równań.
Jak widać jest dużo pracy.Każdy wskaźnik ma trochę inną charakterystykę (zakres,liniowość).Trzeba w związku z tym dobrać przekładnie oraz zębatki aby skala pokrywała 0 do 360 stopni.
Na koniec chciałbym podziękować codeking za pomoc teoretyczną oraz EGHI za pomoc w realizacji precyzyjnego wykonania panelu.Projekt jest w fazie realizacji,ale jest nadzieja,że będzie zrealizowany i konkurencyjny do projektu na viperpits,który kosztuje około 300 EUR bez silniczków (4x20 EUR).
(http://img705.imageshack.us/img705/7854/rpmskala.th.jpg) (http://img705.imageshack.us/i/rpmskala.jpg/)
-
Ciesze się, że mogłem pomóc, aż tak dużo pracy przy tym nie ma, kwestia ustalenia wartości min i max tych dwóch zakresów dla pozycji serwa. Przekładnie nie trzeba dokładnie takiej by zakres serwa był 0-360. Równie dobrze może być 0-400 itp. Zawsze można obciąć trochę zakres pozycjonowania (zamiast 0-1023 używać np. tylko 155-950). Trzeba się tylko zdecydować jak to zrealizować, szukać przekładni 2:1 czy wziąć inną dostępną (2.5:1 itp.). Myślę, że wkrótce powstanie fajny ze wskaźnikami dla Falcon'a po bardzo małych kosztach (w porównaniu z 300E z viperpits).
Zrobiłem prototyp pod połowę mniejsze, może być ciężko.
(http://img12.imageshack.us/img12/6493/dsc00291cj.th.jpg) (http://img12.imageshack.us/i/dsc00291cj.jpg/)
Czy Ty posiadasz jakąś maszynkę CNC ? Bardzo ładnie obrobione pleksi.
-
vito,
patrząc na ten rysunek myślę, że nie potrzeba 360. Przełożenie 2:1 powinno wystarczyć.
codeking,
wspomagam się frezarką ręczną. Frez do drewna zastąpiłem frezem do plexi. Mam dostęp do profesjonalnych narzędzi które stosuje się przy budowie i montażu mebli kuchennych. Wycinając precyzyjnie kilka blatów tygodniowo, można dojść do wprawy :004:. Właściwie to mogę wyciąć każdy kształt (np. panele) napisów niestety nie zrobię takim sposobem.
-
Witam,chciałbym uzupełnić informację na temat skalowania wskaźników,które sprawiają problemy.Takim wskaźnikiem jest FTIT Fan Turbine Inlet Temperature.Problem polega na tym,że w czasie normalnej pracy silnika bez awarii temperatura nie przekracza 8 na skali (na skali jest mnożnik x 100).Skala kończy się na zakresie 12 a rozpoczyna na 2.W czasie rozruchu silnika można uchwycić punkty poniżej 6 pauzując symulator.Te informacje nie wystarczają do skalowania miernika FTIT,ponieważ nie wiemy jakim wartościom na skali odpowiada wartość FTIT przechwycona z pamięci współdzielonej Falcona.
Z pomiarem mocy silnika RPM nie było problemu ponieważ wartość przechwycona z pamięci współdzielonej Falcona odpowiadała liczbie na skali wskaźnika.Jak widać niektóre parametry mogą sprawiać problem.Myślę,że problem skalowania FTIT zostanie rozwiązany gdy będę dysponował przekładnią dającą pełen zakres wychylenia wskazówki.
-
Witam
Ostatnio skończyłem budowę nowej skrzyneczki do mojego kokpitu. Wybór padł na FMC do Boeinga 737. Konstrukcje oparłem na MJOY-u. Oto wyniki :
(http://img19.imageshack.us/img19/1952/fmc02.th.jpg) (http://img19.imageshack.us/i/fmc02.jpg/) (http://img19.imageshack.us/img19/6651/fmc03.th.jpg) (http://img19.imageshack.us/i/fmc03.jpg/)
W Mjoy-u są 64 przyciski a w FMC wyszło 70 więc musiałem wykorzystać toggle jak normalne przyciski, ale najważniejsze, że wszystko działa. Oczywiście nie ma żadnego monitora / to tylko atrapa, aby lepiej wyglądało / na razie nie jestem w stanie czegoś takiego zrobić - może kiedyś. Dzięki aplikacji DK udało mi się zaprogramować skrzyneczkę aby działała z 737NG od PMDG. Oto dwa filmiki pokazujące jak to działa :
ftp://zajac.homeftp.net/Video_DK/FMC_01.avi
ftp://zajac.homeftp.net/Video_DK/FMC_02.avi
pozdrawiam Zając
-
Dla osób, które nie mogą korzystać z ftp-a wrzuciłem oba filmiki na youtube
http://www.youtube.com/watch?v=5Cy6hU7FIrw&feature=channel
http://www.youtube.com/watch?v=lr5aLhI-wgM&feature=channel
pozdrawiam Zając
-
zajac,
rewelacja!!!! Nie wiem czy widziałeś moje MCDU ( gdzieś tam na forum wrzuciłem foty), ale przy tym to amatorka :).
Jestem ciekaw skąd wziąłeś takie przyciski? Wygląda jak jakiś seryjny produkt.
Powinieneś tam wstawić jakiś LCD np. od PS1 lub mini TV 5in i będzie full wypas FMC. Polecam ten drugi, mimo jego wypukłości ekranu i gabarytów ma dwa plusy, jest tani i ma szeroki kąt widzenia. To co wyświetlasz na dużym monitorze wrzucisz na mały i gotowe. :)
Twoja konstrukcja to najlepszy przykład jak można z pomocą DK sterować opornymi na domowe wynalazki symulatorami.
Gratuluje i czekam na news z kolejnych konstrukcji. ;)
-
Dołączam się do EGHI,gratulacje.Faktycznie mały monitor ładnie uzupełniłby projekt.W tym miejscu musimy docenić DK codekinga.
-
Witam,
mała migawka z testu mechanizmu nad którym pracujemy:
http://www.youtube.com/watch?v=7nEDJGdOK5k
Sorry za kiepską jakość, ale myślę, że widać co trzeba :)
-
Jestem ciekaw skąd wziąłeś takie przyciski? Wygląda jak jakiś seryjny produkt.
Kupiłem Je tutaj - http://www.trim-pot.com.pl/produkty.php?id_produkt=4425 , ale stan magazynowy obecnie wynosi zero / chyba wszystkie wykupiłem /, podobne są na TME - http://www.tme.eu/html/PL/mikroprzelaczniki-podswietlane-do-druku-firmy-highly/ramka_1451_PL_pelny.html - jeden taki jest z diodą w FMC. Obudowę kupiłem na wolumenie w Warszawie - http://www.piekarz.pl/index.php?page=offer&item=32233 .
Powinieneś tam wstawić jakiś LCD np. od PS1 lub mini TV 5in i będzie full wypas FMC.
Niestety chyba nie dam rady, przynajmniej w tej wersji - bardzo mało miejsca w środku
(http://img168.imageshack.us/img168/1646/fmcinside.th.jpg) (http://img168.imageshack.us/i/fmcinside.jpg/)
Jeszcze jedna sprawa a mianowicie sterowanie, aby działał DK z modułem mouse cały panel FMC na kompie musi być widoczny / musi być miejsce do klikania /, druga rzecz przynajmniej przy PMDG trudno wydobyć w osobnym oknie sam ekran FMC, więc taki FMC z ekranem zostawiam na razie na później.
Mam taką technologie, że najpierw sprawdzam co da się programowo wysterować a później robię pod to skrzyneczki, wtedy nie mam przykrych niespodzianek, że coś nie działa. Żeby dobrze zrobić FMC z ekranem trzeba mieć inny soft np. Project Magenta, ale kosztuje on furmankę pieniędzy. Kupne FMC mają specjalne sterowniki do współpracy np. z PMDG a ja ani codeking takimi nie dysponujemy - firmy płacą PMDG za ich udostępnienie, pewnie dlatego są takie drogie te FMC.
Fajna rzecz te serwa, gratulacje, ale dla mnie to jeszcze daleka przyszłość, ale się dokładnie przyglądam na przyszłość.
Pozdrawiam - zając / w razie pytań co do budowy FMC i oprogramowania chętnie odpowiem /
-
przy PMDG trudno wydobyć w osobnym oknie sam ekran FMC,
W F16 Lago do FS9 udało mi się wydobyć hud, wskaźniki centralnej konsoli, mfd przy pomocy Fs Panel Studio. Zrobiłem dodatkowe okna które można przenieść na inny ekran. Nie mam PMDG, nie wiem czy jest to jakoś zabezpieczone, ale jeśli ktoś posiada ten samolot oraz panel studio, może spróbować wydobyć sam ekran FMC. Dodatkowe okno przenosisz na inny monitor, reszta pozostanie bez zmian. Tak bym to zrobił :004:
-
Niestety chyba nie dam rady, przynajmniej w tej wersji - bardzo mało miejsca w środku
(http://img168.imageshack.us/img168/1646/fmcinside.th.jpg) (http://img168.imageshack.us/i/fmcinside.jpg/)
To zdjęcie doskonale pokazuje ile trzeba włożyć pracy (czasu i cierpliwości) aby te nasze "zabawki" zaczęły "świecić". Tym bardziej gratulacje dla zajaca.
Fakt, mało miejsca, ale wyświetlacz może trochę wystawać ponad górną powierzchnię obudowy, jakaś prosta ramka i będzie OK.
EGHI - brawo, pokaż "serce" mechanizmu - przekładnie, mocowanie.
-
Witam,ja także wykonałem model serwa z przekładniani do testów.
(http://img229.imageshack.us/img229/923/serwo2.th.jpg) (http://img229.imageshack.us/i/serwo2.jpg/)
Jest to tylko model,ale działa w pełnym zakresie podobnie jak model EGHI.
(http://img186.imageshack.us/img186/1777/serwo1.th.jpg) (http://img186.imageshack.us/i/serwo1.jpg/)
-
Kolejny test:
http://www.youtube.com/watch?v=BHZIm7m93uQ
Tym razem z Falconem.
Panowie którzy napisali skrypt, dobrze się spisali. :004:
-
Witam,
projekt wskaźników jest bliski ukończenia. Mechanizm znalazł się już na swoim miejscu, teraz trzeba dorobić jakieś maskownice tarcz i zrobić kilka poprawek. Walczę z podświetleniem, chcę zmienić na kolor zielony, ale jest problem z doborem odpowiednich diodek. Białe jak widać świecą jasno czego nie mogę powiedzieć o zielonych. Testowałem różne, ale zawsze marny efekt. Może ktoś z was wie jakie są najlepsze? Jakiś sprawdzony sklep, firma? Dodam, że wiem jak obliczyć rezystancję, napięcie itd. Jednak wszystkie, które dotąd testowałem dawały słabe światło.
(http://img697.imageshack.us/img697/1003/p1020650k.th.jpg) (http://img697.imageshack.us/i/p1020650k.jpg/)
(http://img704.imageshack.us/img704/8282/p1010646z.th.jpg) (http://img704.imageshack.us/i/p1010646z.jpg/)
(Wspomina się tutaj o 300Euro za komplet, ja wydałem około 10 + sterownik servo :004:)
-
Witam,
zakończyłem skalowanie ostatniego wskaźnika NozzlePos.Nie byłoby problemu z tym wskaźnikiem podobnie jak z pozostałymi gdyby EGHI nie zauważył jego dziwne zachowanie w OF.Ja testowałem serwa w AF i tam nie było problemu.Okazało się,że w pamięci współdzielonej OF jest błąd związany z zmienną Nozzle.W tym momencie powstał problem jak to rozwiązać.W końcu zdobyłem algorytm lub raczej program jak emulować wskaźnik Nozzle na podstawie innych parametrów takich jak RPM,Alt (wysokość baryczna)oraz FF (przepływ paliwa).W tym momencie pomoc codeking okazała się bezcenna.Bez jego pomocy nie powstałby skrypt.
Jak się zachowuje dysza wylotowa wg.powyższego algorytmu.
W zakresie mocy RPM od 0 do 58% Nozzle jest równe 0 %.Od 58% do 62% następuje pełne jej otwarcie tzn.100%.W zakresie 62% do 70% Nozzle wynosi od 100 do 98%.W zakresie 70% do 83% RPM następuje zamykanie dyszy od 98% do 6.8%.
Najciekawszy jest zakres 83% do 103%.W tym zakresie dysza wylotowa może przyjmować warości od 0 do 100% w zależności od 3 parametrów RPM,FF oraz Alt.Są odpowiednie tabele opisujące to zachowanie.
RH powstał dzięki projektowi EGHI,pomocy ze strony codeking oraz moim testom.
-
Panowie vito_zm i codeking!!!
Kawał dobrej roboty, gratuluje. Z tego co mi wiadomo, to jesteśmy pierwsi którym udało się uruchomić wszystkie wskaźniki prawej konsoli na servo-mechanizmach :001: (O Falconie piszę, rzecz jasna.)
-
To już tylko pozostało opatentować i sprzedawać :004: Taki żart oczywiście.
Ciesze się, że mogłem pomóc, czekam jeszcze na jakiś filmik, na którym będzie ładnie widać działanie wszystkich wskaźników (za mniej niż 300 Euro :001: ).
-
Dodam tylko,że na viperpits też jest zainteresowanie tym projektem.
-
Brawo Panowie!
W takim razie zabieram się za rozszrzenie dla serwo do mojego projektu.
-
To już tylko pozostało opatentować i sprzedawać :004: Taki żart oczywiście.
Nawet o tym nie myślę. Zainteresowanie małe a w takiej wersji jeśli ktoś nie buduje kokpitu, to nie ma sensu. Można pomyśleć o projekcie wersji biurkowej, taki mini panel w estetycznie wykonanej obudowie. Tym mogę się zająć, jednak budowa już w własnym zakresie. Mimo prostoty urządzenia ręczne wykonanie do łatwych nie należy. Wszystko musi być precyzyjnie wycięte i dopasowane. Nie mówię, że to nie możliwe, jednak łatwiej zlecić to firmie która wytnie na CNC lub laserze. Jeśli pojawią się chętni mogę zrobić dokumentacje.
Dodam tylko,że na viperpits też jest zainteresowanie tym projektem.
Jakaś alternatywa dla chyba jedynego projektu, który tam sprzedają :)
Skalarki,
liczę na Ciebie. Jeśli się uda, będzie to projekt wolny od komercyjnych rozwiązań ;)
A teraz filmik, zapomniałem włączyć podświetlenie, ale chyba widać jak wasz skrypt działa?
http://www.youtube.com/watch?v=ZQeTpNpY-Vg
-
Bardzo ładnie to wyszło.Ten pomysł z FF na LCD jest bardzo dobry.DED jest też dobrym pomysłem,ale jest trochę małe,takie mam wrażenie.Moje gratulacje EGHI.Czas pomyśleć o nowym projekcie może DED.
-
Witam,otrzymałem od EGHI panel z wskaźnikami.Moje gratulacje dla projektu oraz jego wykonania.Tutaj precyzja wykonania jest bardzo istotna.Mam na myśli łożyskowanie,luzy pomiędzy zębatkami oraz wzajemne relacje pomiędzy elementami.Słowa uznania dla EGHI.Pozostał jeszcze u mnie jeden problem do rozwiązania,przyklejenie osłon z pleksi do obudowy.Zastanawiam się jak to zrobić nie niszcząc osłon.Konkretnie jaki użyć do tego celu klej.Na drugim zdjęciu jest projekt z viperpits (300 EUR plus cena 4 silniczków 80 EUR).Tutaj użyto prawdopodobnie uszczelek z gumy,tak myślę.
(http://img196.imageshack.us/img196/7864/rhgauges.th.jpg) (http://img196.imageshack.us/i/rhgauges.jpg/)
(http://img710.imageshack.us/img710/4931/rhviperpits.th.jpg) (http://img710.imageshack.us/i/rhviperpits.jpg/)
Jeśli ktoś ma jakiś pomysł jaki użyć klej do przymocowania osłon proszę o radę.
-
vito,
sam jeszcze nie zainstalowałem tych szkiełek u siebie. Najlepszy klej do tego celu to bezbarwna masa, wyciskana z pistoletu elektrycznego. Nie uszkodzi plexi, dobrze trzyma i w razie potrzeby łatwo to zerwać.
Pomysł z gumą jest dobry, też o tym myślę. Może jakąś starą dętkę od roweru równo przyciąć w paski, naciągnąć na szkiełko i przykleić? Guma zamaskuje miejsce klejenia i zrobi się czarna obręcz.
-
Powstaje nowa platforma dla sim-builder'ów - simOUT. Wspólnie z Zającem kombinujemy proste w budowie i tanie urządzenia do sterowania wyświetlaczami LCD (HD44780), diodami LED, wyświetlaczami 7-segmentowymi i może coś jeszcze (serwa). Interfejsem połączeniowym z PC jest RS232, archaizm, ale z powodzeniem będzie można zastosować przejściówkę na USB. Sterowanie oczywiście z aplikacji DomowyKokpit (odpowiedni moduł już powstaje). Główne założenie projektu to "tanie i proste", żeby złożenie i uruchomienie nie było trudniejsze od MJoy'a.
Prototyp pierwszej płytki (4xLCD + 40xLED) po drobnych poprawkach ożył :)
Info i zdjęcia na stronie: http://www.simout.wa.pl/ (http://www.simout.wa.pl/)
-
Panowie!
Genialny pomysł z tym projektem. Jestem raczej ograniczonym elektronikiem lecz na bazie planów i opisu będę w stanie wykonać sobie zabawki o których rozmawiacie w tym wątku (i nie tylko). Wiedzcie, że macie na prawdę spore grono obserwatorów. Osobiście czynnego udziału w rozmowach nie biorę (nie chcę się przypadkiem zbłaźnić :020:) ale czytam z wypiekami na pysku.
Gratulacje raz jeszcze!
-
Gratuluję,jest to bardzo dobry projekt.Jeśli będzie tak łatwy w uruchomieniu jak MJoy to może być następnym "hitem" na tym forum.Budując pierwszy kokpit na bazie MJoya musiałem zrezygnować z alarmów z powodu braku odpowiedniej karty (prostej w obsłudze).Teraz każdy może rozpocząć budowę paneli do kokpitów na bazie MJoya,projektu Damosa oraz simOUT.
Moim zdaniem najważniejsze w tym projekcie jest to,że jest zintegrowany z softem DK.DK ma tę zaletę,że umożliwia sterowanie elementów wykonawczych z symulatora np.Falcona lub FSX.
Jeszcze raz gratuluję i mam pytanie.Przypuszczam,że użyliście uP.Jak będzie programowany (PonyProg)?
-
Zastosowany jest mikrokontroler Attiny2313, programowanie przez PonyProg takim samym programatorem jak MJoy. Złożenie całości jest naprawdę proste i nawet mniej lutowania niż w MJoy bo nie trzeba lutować tylu diod.
-
To ułatwi programowanie.Policzyłem wyjścia na LCD oraz LED,jest ich 4 + 40 tak jak jest w opisie.Są tam też inne "piny-łączówki".Powstaje następne pytanie dotyczące 7seg-LED.Czy będzie to fizycznie inna karta ,czy dodatkowa "córka"?
Ja nie mam wyprowadzonych na zewnątrz styków RS232 oraz LTP,dlatego jestem zainteresowany testem tej karty z przejściówką USB-RS232.Czy będziecie robić testy związane z tym interfejsem?Kolejne pytanie dotyczy możliwości zakupu płyty drukowanej,przybliżony termin oraz wstępna cena.
-
WoW Panowie pełne uznanie dla Was.
Tego nam brakowało, o ile FSLCD był pewnym rozwiązaniem, to jednak pakowanie wszystkich danych wyjściowych na jeden czy dwa wyświetlacze LCD wg mnie nie było eleganckim rozwiązaniem.
Tutaj już widzę 4xLCD, do tego diody świecące, i zapowiedź kontroli LEDów 7segmentowych - w końcu prosty simbuilder będzie mógł wyprowadzić upragnione kontrolki oświetlenia oraz stanu podwozia.
W razie czego służę oprawą na http://mjoy16.googlepages.com
Pozdrawiam
-
Powstaje następne pytanie dotyczące 7seg-LED.Czy będzie to fizycznie inna karta ,czy dodatkowa "córka"?
Będzie dodatkowa płytka-córka dołączona do tej pokazanej na stronie. Jeśli będzie trzeba to będzie ona także samodzielna bo to nie jest duży problem.
Ja nie mam wyprowadzonych na zewnątrz styków RS232 oraz LTP,dlatego jestem zainteresowany testem tej karty z przejściówką USB-RS232.Czy będziecie robić testy związane z tym interfejsem?
W tym tygodniu sprawdzę działanie z przejściówką USB.
Kolejne pytanie dotyczy możliwości zakupu płyty drukowanej,przybliżony termin oraz wstępna cena.
To zależy jeszcze od testów, u mnie płytka działa, wprowadzam jeszcze poprawki do wsadów. Zając musi też płytkę sprawdzić żeby potwierdzić działanie. Więc może uda się w przyszłym tygodniu kombinować już zamówienie docelowej płytki. Płytka jest mniejsza od płytki MJoy'a więc cena nie powinna być większa. Trzeba wziąć pod uwagę fakt, że pierwsze zamówienie będzie także zawierać trwałą dokumentację więc im więcej płytek będzie zamówionych tym tańsza będzie jedna sztuka.
Tutaj już widzę 4xLCD, do tego diody świecące, i zapowiedź kontroli LEDów 7segmentowych - w końcu prosty simbuilder będzie mógł wyprowadzić upragnione kontrolki oświetlenia oraz stanu podwozia.
Wyświetlacze 7-segmentowe są już obsługiwane bo 40 diod to 40/8 = 5 wyświetlaczy 7-segmentowych. Planowane są płytki z obsługą 5 wyświetlaczy a także duża płytka dla wyświetlaczy, która obsłuży 30 wyświetlaczy.
Więcej o samych płytkach może napisać Zając bo On je projektuje i wychodzi mu to znakomicie :)
-
Panowie gratuluje,
projekt powinien zachęcić niezdecydowanych do budowy paneli, kokpitów.
Codeking,
rozumie, że w DK będzie dodatkowy moduł do SimOut, czy będziesz wprowadzać jakieś zmiany w sterowaniu? Tworzenie skryptu jak dotychczas?
-
rozumie, że w DK będzie dodatkowy moduł do SimOut, czy będziesz wprowadzać jakieś zmiany w sterowaniu? Tworzenie skryptu jak dotychczas?
Tak, będzie moduł udostępniający zmienne wyjściowe, tak jak moduł SkalarkiIO.
-
Ja nie mam wyprowadzonych na zewnątrz styków RS232 oraz LTP,dlatego jestem zainteresowany testem tej karty z przejściówką USB-RS232.Czy będziecie robić testy związane z tym interfejsem?
Dzisiaj sprawdziłem działanie z tanią przejściówką USB (cena < 9 PLN) w systemie Windows Vista HP x64 - działa bez problemu :)
-
To bardzo dobra wiadomość.Czekam na wiadomość o zamówieniach.Przy okazji pytanie lub sugestia.Czy będzie możliwość prostego testu wyjść coś podobnego do SVMapper?Jest to bardzo przydatna funkcja,w zasadzie niezbędna.Gratuluję postępów i życzę dalszych sukcesów.
-
Mod
Czy będzie możliwość prostego testu wyjść coś podobnego do SVMapper?
Moduł dla DK będzie miał taką funkcję, najprawdopodobniej będzie identyczna z tą z modułu SkalarkiIO.
-
Witam !!
Przepraszam, że nie odzywałem się w sprawie ostatniego projektu jaki z Codekingiem robimy / a raczej projektu Codekinga ja tylko pomagam ile mogę /, ale robiłem aktualizacje strony o smiOUT - teraz jest już zaktualizowana. W miarę możliwości zawarłem tam wszystkie informacje na temat tego projektu oraz warianty dalszego rozwoju, sa dwie opcje, więc zapraszam na stronę www.simout.wa.pl oraz do dyskusji, która wersja będzie lepsza i którą lepiej dalej realizować.
pozdrawiam Zając
-
Kilka uwag ogólnych.Obie wersje są interesujące i mają swoje odpowiedniki w innych projektach np.wersja modułowa ma odpowiednik w OpenCockpits a All in One w projekcie Skalarki.Obie wersje mają zalety i wady i dlatego nie ma sensu je omawiać.Prawdopodobnie każdy użytkownik ma swoje preferencje.Ja stosuję u siebie wersję modułową,ale to jest związane z projektami OC.
Chcę zwrócić uwagę na jedną istotną rzecz w wersji modułowej,na interfejs DATA.Jeśli założymy rozprowadzanie sygnałów na odległość np.2 m lub więcej to musi być odpowiedni interfejs.Są dostępne nadajniki i odbiorniki takich interfejsów.W rozwiązaniach OC mają zwykłe wejścia i wyjścia z układów scalonych TTL lub CMOS.W projekcie Skalarki jest "odpowiedni interfejs" o ile mnie pamięć nie myli.Myślę,że Skalarki może coś doradzić chociaż projekt Codeking jest w pewnym sensie konkurencyjny (brak USB).Tyle moich uwag na gorąco.Jeśli o mnie chodzi to zamówię każdą wersję
pozdrawiam i czekam na listę
vito_zm
-
Witam ponownie.Ponieważ nie ma chętnych do dyskusji to postanowiłem uzupełnić swoją wypowiedź.Na początek pytanie do kolegów czy macie koncepcję interfejsu dla wersji modułowej,mam na myśli sygnały.Jakiś czas temu prowadziliśmy na tym forum dyskusję z Damosem na temat takiego interfejsu w jego projekcie.Z tego co pamiętam to były tylko 3 sygnały dane nadawane,odbierane oraz zegar i wyspecjalizowany układ scalony.Jest to dobre rozwiązanie,mało połączeń oraz odporność na zakłócenia.
Wspomniane projekty OC mają trochę przestarzały interfejs równoległy tzn.dane,adresy oraz sygnał zapisu.U mnie ten interfejs pracuje poprawnie,ale mam małe odległości rzędu 1 m.Sygnały są na wyjściach układów HC259.
Wracając do schematów blokowych obu wariantów to dla mnie interesujący jest simOUT z możliwością podpięcia dodatkowych pcb dla 7-seg. lub simOUT MASTER z dodatkowymi modułami
pozdrawiam i życzę powodzenia
-
Wyjaśnię jak działają płytki i port DATA.
Każdy uC ma sprzętową obsługę UART czyli RS232. Płytka MASTER zawierająca układ MAX232 służy tylko i wyłącznie do konwersji napięć z RS232 <-> UART. Dodatkowo ma 6 gniazd więc można podłączyć 6 uC. Każdy uC w naszym projekcie może tylko odbierać dane od PC (tylko wysyłanie poleceń z PC do uC), więc potrzebna jest tylko jedna linia danych (RX). Gniazda DATA zawierają tylko linie VCC, GND i RX. Płytka simOUT MINI to połączenie płytki MASTER, LCDx4 i LEDx40 (na płytce pozostają 4 gniazda DATA). Dane wysyłane z PC na dany port RS232 trafiają do WSZYSTKICH uC podpiętych do MASTER. Dane zawierają identyfikator urządzenia (uC) do którego są adresowane i tylko uC z takim ID (zapisanym we wsadzie do uC) interpretuje te dane, pozostałe uC - ignorują je.
Nie ma więc już kwestii portów rozszerzeń do rozwiązania bo to załatwia nam specyfika RS232 - wiele urządzeń może "słuchać".
Z powyższym wiąże się ważna rzecz - identyfikator urządzenia. Ten identyfikator jest zapisany w wsadzie, więc do każdego urządzenia trzeba wgrać inny wsad. Wszystkie oczywiście przygotuje.
Więc kwestia tego jakie płytki robimy. Docelowo będzie tak, że każda płytka zawiera min. dwa gniazda DATA. Jedno aby połączyć płytkę do MASTER (lub innej płytki) a drugie aby do niej podłączyć kolejną płytkę. Ułatwi to stworzenie np. panelu radia gdzie potrzebne będzie kilka(naście) wyświetlaczy 7-segmentowych.
Nie wiemy jeszcze jaka może być max. długość przewodu DATA - bardziej precyzyjnie - jaka jest max. odległość pomiędzy MAX232 a uC. To jest do sprawdzenia i w przyszłym tygodniu zostanie sprawdzone. Kwestia zasilania, wyświetlacze LCD (HD44780) nie potrzebują dużo prądu do komunikacji, ale mają podświetlenie diodami więc one jednak "coś" potrzebują. Układy LED i wyświetlaczy 7-segmentowych to ta sama płytka tylko inne gniazda do podpięcia LED i wyświetlaczy. Diody są multipleksowane, w jednym momencie zapalone może być max. 5 diod. Jeśli średnio policzymy prąd dla diody 20mA to da nam 100mA na jeden układ LED (to samo dla wyświetlaczy 7-segmentowych). Jeśli będziemy wiedzieć ile prądu potrzebuje wyświetlacz to łatwo będzie policzyć jaki zasilacz potrzebujemy do zasilania urządzeń połączonych razem do jednej płytki MASTER (lub MINI lub MAX). Najlepiej chyba użyć starego zasilacza od PC - mój ma 20A dla 5V.
Nic nie stoi na przeszkodzie aby zrobić wszystkie płytki, tylko trzeba wziąć pod uwagę koszt pierwszego zamówienia, które zawierać będzie koszt trwałej dokumentacji płytek. Im więcej płytek zamówimy tym mniejszy wyjdzie koszt jednostkowy.
EDIT:
Zapomniałem napisać: moduł do DK zaczyna działać :)
-
Dzięki za wyjaśnienia.RS232 dla naszych potrzeb wystarczy mam na uwadze długość kabla.Ja stosuję zasilacz od PC z którego rozprowadzam napięcie do poszczególnych kart.Można to robić opcjonalnie tzn.tak jak w OC zasilanie albo z Master albo (mostek) indywidualnie każda karta.Można zrobić identyfikację karty oraz jej programu (mam na myśli funkcję jaka ma wykonać-sterowanie) ustawiając adres za pomocą hardware (dekoder) lub bardziej profesjonalnie inny wsad.Bardzo mi się podoba Twoje rozwiązanie.
Co do wariantu to myślę,że koszty też trzeba brać pod uwagę.Wersja prototypowa jest bardzo atrakcyjna.Dla porównania w OC aby to zrealizować w przybliżeniu te same elementy wykonawcze to trzeba kupić kartę Master oraz USBLCD (4LCD oraz kilka wyjść więcej).Cena w OC Master 25 EUR oraz USBLCD 21 EUR (jako kit) plus WAT oraz przesyłka.Wasz projekt powinien być tańszy tak mnie się wydaje.
-
Witam !!!
Przed chwilą zaktualizowałem stronę www.simout.wa.pl - można już obejrzeć projekty płytek PCB, ich możliwości i konstrukcje. Co do wariantów to są takie jakie wydawało mi się, że będą najpotrzebniejsze. Oczywiście chętnie zrobię inne wersje - czekam na propozycje co było by najbardziej potrzebne w projekcie.
Co do testów kawałek modułu do DK / dzięki Codeking / działa więc testy dalej trwają. Udało mi się jednocześnie podłączyć 3 wyświetlacze LCD / wiecej naraz nie miałem :001: / i wszystko pięknie działa.
pozdrawiam - Zając
-
Panowie, wszystko ładnie i pięknie, ale może mi któryś z was wytłumaczyć czemu nie robicie tego od razu pod USB ?
-
Panowie, wszystko ładnie i pięknie, ale może mi któryś z was wytłumaczyć czemu nie robicie tego od razu pod USB ?
Tak jest prościej :) Wiemy, że RS to przeżytek i nawet przejściówka to też takie "głupie obejście" bo po stronie systemu to dalej jest RS. Ale żeby mieć USB to trzeba albo zastosować MicroChip'a albo przynajmniej Atmega8. Koszty rosną, ilość elementów również. Miałem już gotowe te urządzenia, Zając namówił mnie na podzielenie się nimi, zaprojektował płytki, zadziałały więc można się podzielić z innymi.
vito_zm
Cena zdecydowanie mniejsza od cen OC.
Zając
Świetna robota z tą stroną.
-
Ale żeby mieć USB to trzeba albo zastosować MicroChip'a albo przynajmniej Atmega8. Koszty rosną, ilość elementów również. Miałem już gotowe te urządzenia
Ja myślę,że problem jest po stronie oprogramowania USB.Damos miał ten interfejs opracowany,ale zniknął z forum.OC stosuje uP,które mają USB w kości.Cena nie jest wygórowana.Problem jest także w tym,że projektanci w tym przypadku Codeking mają opanowane określone uP.Poznanie nowego uP to koło 200 str dokumentacji.Jest jeszcze problem programatora,ale to można rozwiązać.Ja też się zastanawiałem czy nie wejść w programowania określonej rodziny uP,ale doszedłem do wniosku,że straciłbym około roku na ten temat.Dlatego uważam,że lepszym pomysłem jest współpraca np.Zając Codeking,gdzie każdy ma jakąś umiejętność.
Bardzo liczyłem na duet Damos Codeking,ale ten pierwszy zniknął z forum.Sundowner wiem,że jesteś programistą,może coś doradzisz.Można próbować zastosować inne rozwiązanie np.wyspecjalizowany układ dla USB podłączony do uP.W tym przypadku programista nie musi stosować innego uP.
Wiem,że na forum są programiści,ale w roli raczej kibiców,dlatego Codeking jest praktycznie sam.
Gratulacje Zając bardzo ładnie to zrobiłeś.
Jeszcze jedna uwaga na koniec.Śledziłem postęp w opracowywaniu nowych kart w OpenCockpits.Wystartowali skromnie sterując Master z LPT (sygnały TTL).Później zastosowali interfejs USB oraz nową kartę do połączenia z PC,ale pozostawili starą kartę Master,która współpracuje z nową.
Czyli zrobili krok do przodu (nowa karta z USB),ale pozostawili stare rozwiązanie Master.Jednocześnie powstały nowe karty,które mogą pracować autonomicznie poprzez USB np.USBServo lub USBLCD.Największą zaletą projektów OC jest soft a konkretnie SIOC,oraz programy do testów.Jeśli chodzi o hardware to nie mają najnowszych rozwiązań.Projekt Skalarki jest bardziej zaawansowany technologiczne.
Reasumując największą zaletą nowego projektu nie jest hardware,ale DK.Nawet projekt Skalarki będzie "martwy" dla mojego symulatora jeśli ktoś nie napisze programu łączącego platformę z symulatorem.
Jeśli ktoś na forum najlepiej programista znający USB może się włączyć do dyskusji to będzie to z pożytkiem dla projektu.
-
Jeśli chodzi o "dorobienie" USB to jest dostępny układ FT232, jest to po prostu przejściówka USB<->RS232 w postaci układu scalonego. Ma też sporo opcji konfiguracyjnych i lepiej działa niż przejściówki po kilka PLN. Np. ta którą posiadam (cena < 10 PLN) ma problemy z prędkością 115200b/s a taką ustawiłem w uC. Gdy podłącze bez przejściówki problemów nie ma (problem jest w przesyłanych danych - ginące lub przekłamane dane). Prędkość będzie obniżona, żeby nie było problemów.
Układ FT232 kosztuje kilkanaście PLN, można nawet kupić złożony układ za < 30 PLN. Wystarczy go wtedy odpowiednio podpiąć zamiast MAX232 w simOUT.
Reasumując największą zaletą nowego projektu nie jest hardware,ale DK.Nawet projekt Skalarki będzie "martwy" dla mojego symulatora jeśli ktoś nie napisze programu łączącego platformę z symulatorem.
Dk obsługuje płytki Skalarki (moduł SkalarkiIO).
Dzisiaj zamiast diod LED podłączyłem wyświetlacze 7-segmentowe na płytce, którą kiedyś Zając zaprojektował i podarował mi do testów. Oto wynik:
(http://img444.imageshack.us/img444/1476/dsc02536w.th.jpg) (http://img444.imageshack.us/i/dsc02536w.jpg/)
-
(http://img697.imageshack.us/img697/5848/p1310719.th.jpg) (http://img697.imageshack.us/i/p1310719.jpg/)
Stolarstwo artystyczne :).
-
Witam !!
Chciałbym parę słów napisać dlaczego nie ma interfejsu USB. W czasie tworzenia projektów zastanawialiśmy się z codekingiem nad umieszczeniem od razu na pcb konwertera rs232->USB. Jedynym jaki by się nadawał to był układ FT232, lecz niestety występuje on w podstawkach smd SSOP28 / odstępy miedzy nóżkami 0,65 mm /. Z racji trudności przy montażu zrezygnowałem z tego pomysłu. Układ ma być z założenia bardzo prosty w montażu - tak jak mjoy, a skoro pracuje z gotowymi przejściówkami po 10 pln to można je właśnie wykorzystać aby mieć USB.
pozdrawiam Zając
-
Witam
Zaktualizowałem stronę www.simout.wa.pl - można teraz zobaczyć projekty w powiększeniu oraz nowy wpis w dziale prototyp.
pozdrawiam Zając
-
Witam ponownie.Na wstępie gratulacje dla EGHI za kokpit oraz dla Zająca za piękne projekty.
Szkoda,że nie mam schematów ideowych,ale z schematów montażowych domyślam się jak jest zrobiony projekt.Dla mnie jest interesujący projekt wersji Mini z dodatkowymi 4 portami.Domyślam się (brak schematu),że na pcb są wyprowadzone łączówki ozn. LCD1-4 dla LCD oraz dla 7-seg-LED.W związku z czym mam pytanie czy wersja Mini steruje 4 LCD,40 LED oraz 4 7seg-LED?
Jakie karty można podłączyć do 4 portów?Czy można podłączyć te z wersji modułowej np. LEDx40.
Jeśli jest taka możliwość to dla mnie wersja Mini z możliwością rozbudowy byłaby idealna.
Przyszedł mi do głowy pewien pomysł.Czy byłby problem zaprojektować np.7seg-LED x 6 lub więcej,ale na wspólnej szynie (mniej połączeń).OC oferuje 2 warianty kart Display.Wariant tak jak u Was oraz z wspólną szyną do 16 7seg.-LED.Jeszcze raz gratuluję projektu i życzę powodzenia.
-
Sundowner wiem,że jesteś programistą,może coś doradzisz. Można próbować zastosować inne rozwiązanie np.wyspecjalizowany układ dla USB podłączony do uP.W tym przypadku programista nie musi stosować innego uP.
Programistą jestem hobbystycznym, a im dłużej w pracy programuję VBA, tym mniej z C++, ADA95 i Asemblera pamiętam :karpik
Zawsze można złożyć płytkę pośredniczącą mogącą przyjmować sygnał z takiego jednego, lub kilku układów i wyrzucać na USB, tylko trochę z tym roboty jest, łatwiej byłoby od razu zacząć z USB, szczególnie, że to pewien standard dzisiaj - i nie bez powodu.
Układem się zainteresowałem, bo kontempluję budowę Radio Stack, AP i konsol INS (z FMC nie latam póki co ;) ), a zagraniczne gotowe układy swoje kosztują.
Chciałbym parę słów napisać dlaczego nie ma interfejsu USB. W czasie tworzenia projektów zastanawialiśmy się z codekingiem nad umieszczeniem od razu na pcb konwertera rs232->USB. Jedynym jaki by się nadawał to był układ FT232, lecz niestety występuje on w podstawkach smd SSOP28 / odstępy miedzy nóżkami 0,65 mm /. Z racji trudności przy montażu zrezygnowałem z tego pomysłu.
Rozumiem, na ten sam problem natknąłem się w układzie zasilającym mikrofon - scalaki MAX1672 są zbyt kurde małe :D
W sumie mam na stanie nadal kilkanaście sztuk PIC18 F4550 i LF4550, chyba trzeba w końcu wziąć się w garść i kupić programator do nich i coś z nimi zrobić konkretnego.
-
Nie chciał bym wchodzić pomiędzy wódkę a zakąskę, ale alternatywą dla FT232 wydaje się być MCP2200 Microchipa. Obudowa też SMD, ale z szerszymi wyprowadzeniami (SOIC).
-
Przejrzałem pobieżnie parametry obu scalaków.Nie ma problemu z montażem MCP2200,co do FT232 to można także polutować ręcznie ale wymaga to koncentracji.Chciałbym zapytać jak wygląda sprawa konfiguracji obu scalaków,czy jest z tym problem.Podają także dla MCP2200 możliwość przekłamań 0.16% od 38400 do 961600 co nie jest dużym błędem.
Z drugiej strony jeśli są gotowe interfejsy to można sobie uprościć zadanie i z tego korzystać.
-
Tego scalaka jeszcze nigdzie nie montowałem, więc nie wiem jak to wygląda w praktyce. Jest to świeży układ (chyba z marca tego roku), dlatego ciężko znaleźć aplikacje z jego zastosowaniem.
-
Domyślam się (brak schematu),że na pcb są wyprowadzone łączówki ozn. LCD1-4 dla LCD oraz dla 7-seg-LED.W związku z czym mam pytanie czy wersja Mini steruje 4 LCD,40 LED oraz 4 7seg-LED?
Na pcb mini są tylko 4 gniazda do LCD, nie ma gniazd do wyświetlaczy 7-seg-LED. Samych gniazd jest 8 z tego powodu, że niektóre LCD mają inne złącza do podłączeń, w związku z tym każde wyjście do LCD jest podwójne, dla oby typów wyświetlaczy. Oczywiście płytka mini obsługuje również 40 LED.
Jakie karty można podłączyć do 4 portów?Czy można podłączyć te z wersji modułowej np. LEDx40.
Jeśli jest taka możliwość to dla mnie wersja Mini z możliwością rozbudowy byłaby idealna.
Tak do tych 4 portów będzie można podłączyć płytki z wersji modułowej.
Sam ostatnio zastanawiałem się jakie wyjścia by się przydały. i zacząłem już projektować pcb z obsługą 40 LED i 6 zestawów / po 5 szt. / 7-seg-LED oraz dwa dodatkowe porty np do LCD. Staram się zmieścić wszystko w wymiarze takim samym lub podobnym jak MJOY, ale wtedy będzie to płytka dwustronna. Czekam na opinie czy nie lepiej zrobić jednostronną, ale będzie około 1,5 raza większa oraz LED-y będą miały po dwa złącza osobne dla anod i osobne do katod / podobnie jak ledx40 /. Wczoraj zrobiłem eksperyment a mianowicie w gnieździe od UC od LCD zaprogramowałem attiny do LED a później podmieniłem scalaki i wszystko działa, wiec pomyślałem, że na każdej płytce można zostawić tylko jedno złącze do programowania i tam programować wszystkie scalaki - duża oszczędność miejsca na pcb i prostsza konstrukcja - też czekam na opinie specjalistów na temat takiego rozwiązania.
pozdrawiam Zając
-
że na każdej płytce można zostawić tylko jedno złącze do programowania i tam programować wszystkie scalaki - duża oszczędność miejsca na pcb i prostsza konstrukcja
Oczywiście tylko na jednej karcie złącze do programowania.
LED-y będą miały po dwa złącza osobne dla anod i osobne do katod /
Tego nie rozumiem chyba,że chodzi o 7seg.-LED,które mogą być z wspólną katodą lub anodą.Z tego co widzę na pcb to jest układ ULN 2003 co sugeruje wspólną katodę.
Co do opcji jednostronnej lub dwustronnej to myślę,że jeśli cena nie będzie wygórowana o opcja 2-stronna jest bardziej atrakcyjna.
Sam ostatnio zastanawiałem się jakie wyjścia by się przydały. i zacząłem już projektować pcb z obsługą 40 LED i 6 zestawów / po 5 szt. / 7-seg-LED oraz dwa dodatkowe porty np do LCD
Proszę o wyjaśnienie tego zestawu jakieś szczegóły.Czy jest to nowa wersja?
-
Witam
Tego nie rozumiem chyba,że chodzi o 7seg.-LED,które mogą być z wspólną katodą lub anodą.Z tego co widzę na pcb to jest układ ULN 2003 co sugeruje wspólną katodę.
Trochę się nie zrozumieliśmy - chodzi o sposób podpięcia LED do złącza na płytce, ale najlepiej zobrazuje to ten rysunek
(http://img707.imageshack.us/img707/8854/diody.jpg)
Proszę o wyjaśnienie tego zestawu jakieś szczegóły.Czy jest to nowa wersja?
To jest pomysł na nową wersje płytki - właśnie ją skończyłem :001: - jest już umieszczony na stronie www.simout.wa.pl wraz z opisem.
Nie chciał bym wchodzić pomiędzy wódkę a zakąskę, ale alternatywą dla FT232 wydaje się być MCP2200 Microchipa. Obudowa też SMD, ale z szerszymi wyprowadzeniami (SOIC).
Dobry pomysł tylko potrzebuje trochę więcej informacji na temat tego układu / schemat podłączenia / oraz informacje od Codekinga, czy w takim układzie jest potrzebny MAX232 i jak taki układ "wkleić" zamiast maxa lub wraz z nim. Myślę, że polutowanie tego "większego" smd nie będzie stanowiło problemu.
pozdrawiam Zając
-
Dzięki za wyjaśnienia,wersja XL dla moich potrzeb jest najlepsza.Ma to co niezbędne jednocześnie umożliwia rozbudowę.
MCP2200 ma w swojej stukturze UARD,który realizuje funkcje RS232. MAX232 jest potrzebny do konwersji napięć portu RS-232 na standard TTL.Jeśli zastosujemy USB to pozostaje tylko problem połączeń np. simOUT XL z dodatkowymi modułami.
Tak jak wspomniałem poprzednio są dostępne tanie uP z wbudowanym USB,ale jest problem nauczenia się tych uP a to wymaga czasu,dlatego jest druga możliwość zastosowania wyspecjalizowanego układu np. MCP2200,który także trzeba "ustawić"(zaprogramować).
Gdyby znalazł się ktoś chętny do analizy tego scalaka pod kątem jego zaprogramowania,możliwości zakupu oraz jego aplikacji to można byłoby o tym pomyśleć.Codeking jest zajęty innymi sprawami,dlatego musiałby to być programista amator lub profesjonalista.Szkoda,że nie ma Damosa na tym forum.
-
Witam ponownie.Przejrzałem pobieżnie dane katalogowe MCP2200 Microchip (34 str.) i muszę przyznać,że wygląda to zachęcająco.Układ jest bardzo tani 7.99 PLN
http://www.tme.eu/pl/katalog/artykuly.html?id_category=100636&id_producer=99&page=6,20#
Można także kupić kit uruchomieniowy za 79 PLN.Jest dostępne narzędzie do zaprogramowania konfiguracji tego scalaka.Jest to opisane w jego katalogu.Trzeba także zakupić kwarc 12MHz,z montażem nie powinno być problemów.
Reasumując decyzja należy do Codeking czy robimy z interfejsem USB czy z RS232 od strony PC.Jest to dodatkowa praca dla Codeking tzn.poznanie tego scalaka i testy.Jest też możliwość,że ktoś znający trochę programowanie przetestuje ten scalak mam na myśli jego konfigurację.Byłoby to duże ułatwienie dla kolegów.Narzędzia do ustawienia konfiguracji są dostępne na stronie Microchip.Ta są moje sugestie.Przepraszam,że sam się za to nie zabieram,ale jestem raczej od hardware
-
Dla mnie to bez znaczenia. Od strony PC ten układ jest instalowany jako wirtualny port COM więc u mnie zmian nie będzie. Może jedynie zmniejszy się wtedy prędkość do wsadów (ale to szczegół). Więc jak ktoś może przetestować ten układ to będzie super.
-
Witam
Jest jeszcze jedno rozwiązanie dla / dla mniej doświadczonych / a mianowicie zastosowanie takich gotowych modułów :
- http://www.allegro.pl/item1008625854_modul_konwertera_usb_rs232_ft232rl_nowy_fv.html
- http://www.allegro.pl/item1005676135_minimodul_usb2_0_rs232_ttl_na_ft232_4_linie.html
Niestety nie są tanie ale mogę przygotować wesje pcb pod te moduły.
Moim zdaniem można spokojnie pozostać przy wersji rs232,a wszystkich, którzy chcą korzystać z portu USB mogą kupić tańsze gotowe konwertery USB->RS232 np. takie :
- http://www.allegro.pl/item992078912_adapter_usb_na_rs232_com_pl_2303_prolific.html
mam podobną przejściówkę i została przetestowana, z tego co wiem Codeking również podobną sprawdzała z powodzeniem.
pozdrawiam Zając
-
Masz rację,jeśli działa na prostej przejściówce to szkoda czasu na rozbudowę karty tym bardziej,że jest to tanie rozwiązanie.
-
Trochę się nie zrozumieliśmy - chodzi o sposób podpięcia LED do złącza na płytce, ale najlepiej zobrazuje to ten rysunek
(http://img707.imageshack.us/img707/8854/diody.jpg)
Ja się zastanawiam, jaki ma sens podpinać dwa przewody miedzy każdą diodą a złączem płytki? Jeśli jest wspólna anoda lub katoda to na wszystkie diody wystarczy jedno złącze, wspólne dla wszystkich diodek.
Wyprowadź mnie z błędu jeśli się mylę? :)
-
Ja się zastanawiam, jaki ma sens podpinać dwa przewody miedzy każdą diodą a złączem płytki? Jeśli jest wspólna anoda lub katoda to na wszystkie diody wystarczy jedno złącze, wspólne dla wszystkich diodek.
Wyprowadź mnie z błędu jeśli się mylę? :)
Masz racje można zastosować wariant z płytki jednostronnej z jednym złączem dla wspólnej anody - tylko jest takie ograniczenie, że wspólną anodę ma tylko 8 diod w jednym rzędzie. Tylko czasami może być problem jeżeli diody są oddalone od siebie w kokpicie wtedy trzeba kombinować. Przy konstrukcji płytki simout XL mogę dołożyć takie pojedyńcze złącze dla wspólnej anody oprócz tych co są a i tak przy takiej konstrukcji jak teraz nie ma szans na jednostronna płytkę.
pozdrawiam Zając
-
Pytam dlatego, że można zmniejszyć ilość kłębów kabli. Jeśli ogranicza się do 8 diod na jedną wspólną anodę, to i tak jest to jakiś rozwiązanie. Zamiast 16 przewodów będzie 9. Rozumie, że każde 8 diod ma wspólną anodę? Czyli na 40 diod będzie tylko 5 dodatkowych wspólnych wyprowadzeń.
Na obrazku zrobiłem ten właśnie sposób podłączenie, jest tam 5 diod ( na 8 będzie identycznie).
(http://img293.imageshack.us/img293/9689/ledssimout.jpg) (http://img293.imageshack.us/i/ledssimout.jpg/)
Pozwoli to wyeliminować prawie połowę okablowania.
-
Nie zwróciłem na to uwagi,ponieważ dla mnie jest oczywiste,że wyprowadzamy tylko jedno połączenie na diodę a drugie jest wspólne u mnie GND.OC wyprowadza sygnały sterujące diody z układu HC259,które sterują anodę diody.Katody diod są połączone wspólną masą GND.Można zastosować tzw.rozdzielacz sygnałów (jak tak mam zrobione),gdzie grupujemy diody po 8 szt.(grupę tworzy 8 sygnałów sterujących plus 1 przewód masy GND).Takie grupy rozprowadzamy po kokpicie wiązką 9 przewodów.
-
Witam
Pytam dlatego, że można zmniejszyć ilość kłębów kabli. Jeśli ogranicza się do 8 diod na jedną wspólną anodę, to i tak jest to jakiś rozwiązanie. Zamiast 16 przewodów będzie 9. Rozumie, że każde 8 diod ma wspólną anodę? Czyli na 40 diod będzie tylko 5 dodatkowych wspólnych wyprowadzeń.
Można w ten sposób - robiąc poprzednie rozwiązanie wzorowałem się na mjoy-u, gdzie na każde 8 przycisków jest 8 wyprowadzeń masy. Myślę, że można zastosować złącze 2x5 gdzie na pianach 1-8 będą sygnały diod a 9 i 10 to wspólna anoda i oczywiście złącze na taśmę 10 żyłową / jestem zwolennikiem takich taśm i mocowania na złącza zaciskane na taśmę /.
Wracając do tematu pcb to udało mi się wykonać projekt simout XL na płytce jednostronnej - bedzie dużo tańsza - / wymiary 180x90mm / - teraz zrobię modyfikacje do domowego wykonania i tu moje pytanie jakie powinna być minimalna szerokość ścieżek oraz minimalne odstępy miedzy ścieżkami, aby taką płytkę można bez problemów wykonać w domu.
oto projekt
(http://img413.imageshack.us/img413/7019/fotort.th.jpg) (http://img413.imageshack.us/i/fotort.jpg/) (http://img202.imageshack.us/img202/3786/sciezki.th.jpg) (http://img202.imageshack.us/i/sciezki.jpg/)
- niedługo szczegóły na www.simout.wa.pl
pozdrawiam zając
-
Witam
Można w ten sposób - robiąc poprzednie rozwiązanie wzorowałem się na mjoy-u, gdzie na każde 8 przycisków jest 8 wyprowadzeń masy. Myślę, że można zastosować złącze 2x5 gdzie na pianach 1-8 będą sygnały diod a 9 i 10 to wspólna anoda i oczywiście złącze na taśmę 10 żyłową / jestem zwolennikiem takich taśm i mocowania na złącza zaciskane na taśmę /.
I o to właśnie chodzi :001:. Pomysł z 10 żyłowymi taśmami jest idealny. Ja też jestem zwolennikiem takich połączeń. Uprości to budowę skrzyneczek, paneli.
Wracając do tematu pcb to udało mi się wykonać projekt simout XL na płytce jednostronnej - bedzie dużo tańsza - / wymiary 180x90mm / - teraz zrobię modyfikacje do domowego wykonania i tu moje pytanie jakie powinna być minimalna szerokość ścieżek oraz minimalne odstępy miedzy ścieżkami, aby taką płytkę można bez problemów wykonać w domu.
Odpowiedź jest prosta- czym grubsze tym lepiej. Z własnego doświadczenia wiem, że nie wszędzie jest możliwość i trzeba zrobić cieniutkie żyłki. Jest to jednak możliwe przy zachowaniu odpowiednich reguł. Mi się udało wytrawić ścieżki 0,2 mm, czego przykładem mogę pokazać domowej robot PCB( jednostronna) pod wyświetlacze 7-seg. (Znalazłem kilka starych fotek)
Na tym foto jest płytka wrzucona do roztworu:
(http://img175.imageshack.us/img175/5269/pb220250.th.jpg) (http://img175.imageshack.us/i/pb220250.jpg/)
Tutaj w połowie trawienia:
(http://img130.imageshack.us/img130/3294/pb220251.th.jpg) (http://img130.imageshack.us/i/pb220251.jpg/)
Przed zmyciem tonera z ścieżek:
(http://img687.imageshack.us/img687/9113/pb220256.th.jpg) (http://img687.imageshack.us/i/pb220256.jpg/)
Efekt finalny:
(http://img688.imageshack.us/img688/9241/pb220257.th.jpg) (http://img688.imageshack.us/i/pb220257.jpg/)
Lutowanie wyświetlaczy:
(http://img571.imageshack.us/img571/6545/pb220254.th.jpg) (http://img571.imageshack.us/i/pb220254.jpg/)\
Docelowo znalazła się w (FCU) autopilocie Airbusa:
(http://img401.imageshack.us/img401/8663/p1240268.th.jpg) (http://img401.imageshack.us/i/p1240268.jpg/)
Wszytko według tego przepisu- http://f16pit.dbv.pl/readarticle.php?article_id=3
Z jedną zmianą, żelazko zastąpiłem laminatorem.
Demonstruje to nie po to, żeby pokazać moje wynalazki. Spostrzegawczy i znający temat zobaczyli na foto, że w pewnych miejscach ścieżki zostały przerwane. Mimo zachowania wszystkich reguł jest ryzyko, że jakaś ścieżka zostanie przerwana. To się łatwo da naprawić, ale ta metoda nie daje 100% gwarancji na jakość. Oczywiście są inne,bardziej zaawansowane sposoby, ja nie znam tańszych więc trzymam się tego schematu. Kolejny problem to wiercenie otworów, wiertła 0.5, 0.8 są bardzo małe i nie każda wiertarka, wkrętarka potrafi złapać tak cienkie wiertło. Do tego dochodzi ilość otworów i precyzja wiercenia.
Nie chcę nikogo zniechęcać do wytrawienia płytki w domu. Jeśli posiadasz drukarkę laserową, laminator, papier kredowy i dużo cierpliwości,możesz próbować. Jednak, płytka pod Simout nie należy do prostych i moim zdaniem lepiej zrobić zbiorowe zamówienie w jakiejś firmie, podobnie jak z Mjoy. Metoda powyżej opisana sprawdzi się w pojedynczych, prostych projektach płytek np. pod konkretne, jednorazowe panele. :)
zajac, w EAGLE można konwertować do PDF, lub Corel?
-
I o to właśnie chodzi :001:. Pomysł z 10 żyłowymi taśmami jest idealny. Ja też jestem zwolennikiem takich połączeń. Uprości to budowę skrzyneczek, paneli.
Ok to sprawa załatwiona tak zostaje - mi również odpowiada takie rozwiązanie
Jednak, płytka pod Simout nie należy do prostych i moim zdaniem lepiej zrobić zbiorowe zamówienie w jakiejś firmie, podobnie jak z Mjoy. Metoda powyżej opisana sprawdzi się w pojedynczych, prostych projektach płytek np. pod konkretne, jednorazowe panele. :)
zajac, w EAGLE można konwertować do PDF, lub Corel?
To proponuje, żeby na simout XL tą dużą zamówić np. w drukowane.pl / tam gdzie mjoy / i wtedy przy zamówieniu 10 szt. koszt jednostkowy wychodzi bez przesyłki 29 PLN - płytka jednostronna a dwustronna około 38 PLN przy jednej sztuce to odpowiednio jednostronna 138 PLN - a dwustronna 161 PLN - jak widać im więcej sztuk zamówimy to będzie taniej. Ceny jakie podałem zawierają zrobienie dokumentacji trwałej - następni będą mieli taniej.
Myślę, że najlepiej będzie jak te duża zamówimy a te mniejsze np master czy te osobne dla każdego rodzaju wyświetlaczy czy diod, każdy będzie mógł sobie zrobić we własnym zakresie lub tez zamówić - odpowiednie pliki umieszczę na stronie.
Projekty robię w SprintLayout 5.0 / nie EAGLE / a eksportować mogę do gerbera / zamówienia / lub bitmapy i pdf-y do własnej produkcji. Te mniejsze projekty postaram się tak zmodyfikować aby ścieżki i odstępy miedzy nimi była jak największe
pozdrawiam Zając
-
To proponuje, żeby na simout XL tą dużą zamówić np. w drukowane.pl / tam gdzie mjoy / i wtedy przy zamówieniu 10 szt. koszt jednostkowy wychodzi bez przesyłki 29 PLN - płytka jednostronna a dwustronna około 38 PLN
Jest to optymalne rozwiązanie.Nie ma sensu robić metodą domową simout XL.Myślę,że znajdzie się kilku chętnych i cena będzie mniejsza.Zgadzam się z EGHI,że można robić małe projekty metodą domową.Przyczyna jest prosta test płytki.
Płyty pcb są testowane w specjalnych testerach,gdzie są specjalne matryce zrobione pod płytę montażową i test jest wykonany przy pomocy programu komputerowego.W praktyce poszukanie zwarcia ścieżki (nie dokładne wytrawienie) będącej np."szyną adresową" powoduje cięcie ścieżki w kilku miejscach itp.Przerwy są trochę łatwiejsze do lokalizacji,ale trzeba znać dobrze schemat ideowy.Dla konstruktora projektu znajdowanie wad typu zwarcie brak połączeń jest uciążliwe ale możliwe do wykonania,dla laika stanowi to duży problem.
-
Witam !!
Przed chwila zaktualizowałem stronę www.simout.wa.pl o płytkę simoutXL w wersji jednowarstwowej / można również pobrać plik pdf z rysunkiem ścieżek /.
Chyba powoli można rozpocząć zapisy na te płytkę / jednostronna simout XL / - ja mogę zrobić zamówienie. Koszty powinny być takie jak dwa posty powyżej. Ja chyba wezmę 3 szt. Jeżeli są chętni na inną wersje to trzeba będzie zrobić inne zamówienie.
pozdrawiam Zając
-
Coś nie tak z tym linkiem. Nie otwiera się.
ps. Działa, to coś u mnie :008:
-
Coś nie tak z tym linkiem. Nie otwiera się.
U mnie też nie działa.
-
Problem na stronie stanowi ramka. Spróbujcie adres http://zajac.homeftp.net/simout/index.htm
W kwestii płytek - wezmę każdą (po jednej sztuce) jaka będzie zamawiana.
Moduł do DK jest już bliski ukończenia, sterowanie LCD, LED i wyświetlaczami 7LED działa, ale brakuje jeszcze okienek konfiguracyjnych.
-
Witam
Dzisiaj uruchomiłem na prototypowej płytce zestaw 5 wyświetlaczy 7-segmentowych. Oto wynik :
http://www.youtube.com/watch?v=ePVA9U-D3B8
encoder podłączony poprzez Mjoy-a a wyświetlacz przez płytkę simOUT. Całość obsługuje DK przesyłając dane do Fs-a i pobierając z niego dane.
Nie widzę natomiast zainteresowania zamówieniem płytek do simout, na razie chyba sam zacznę w domu takie robić będzie taniej niż pojedyncze zamawiać w drukowane.pl
Oczywiście na stronie / www.simout.wa.pl / umieszczę pliki na podstawie których będzie można zrobić takie płytki i potrzebny soft / oczywiście od Codekinga /.
Stronkę też zaktualizowałem więc zapraszam - pozdrawiam Zając
-
Gratulacje Zajac,zainteresowanie jest.Trzeba zrobić listę tak jak było w przypadku MJoya.Każdy zainteresowany będzie się kolejno do niej dopisywał.Ja jestem zainteresowany zakupem płytek.
Proponuję abyś otworzył listę na której będziemy się dopisywać.Mnie interesuje simOUT XL ale widzę,że już powstaje nowa wersja.Interesują mnie także pcb pod 7seg-LED.
-
Zamówienia PCB wydzielone do nowego wątku:
http://www.il2forum.pl/index.php?topic=13101.0 (http://www.il2forum.pl/index.php?topic=13101.0)
-
Otrzymałem konkretne pytania dotyczące budowy kokpitu od podstaw przy założeniu,że mamy do dyspozycji 10 000 zł.Dodatkowo nie znamy się na elektronice oraz informatyce.
Zastanawiam się jak na te pytania odpowiedzieć i mam problem.Jest kilka możliwości realizacji tego pomysłu.
1.Kupić gotowy kokpit od producenta lub z drugiej ręki.Cena jest wysoka.
2.Za wymienioną powyżej kwotę można zbudować tylko desktop czyli część kokpitu bez wyświetlaczy LCD.Proponuję prześledzić wątek od 4 strony
http://www.il2forum.pl/index.php?topic=8494.45
Aby zrealizować taki semipit trzeba zrobić lub kupić najprostszy sterownik np. MJoy i rozpocząć od panelu ICP.
Przy okazji uwaga dotycząca paneli.Można kupić w internecie panele wyposażone w elektroniką lub bez wyposażenia.
Na naszym forum jest kilku kolegów,którzy zrealizowali tylko część kokpitu.Moja propozycja dla początkującego pitbuildera jest taka aby rozpocząć od budowy prostych paneli i je uruchamiać w symulatorze.
Na koniec jedna uwaga ogólna.Z mojego doświadczenia wynika,że budowa kokpitu to proces długotrwały rozłożony na lata.W tej dziedzinie wszysto się zmienia,powstają nowe rozwiązania sprzętowe i programowe.Jest to drogie hobby.
Dla laika najprostszym rozwiązaniem jest zakup gotowego kokpitu lub poznanie jego budowy i robienie tego samemu.Jeszcze jedna uwaga nie ma pojęcia dokumentacji.Można kupić plany konstrukcji na forum viperpits,lub robić to samemu na podstawie zdjęć.Tutaj polecam stronę http://www.xflight.de/
Tyle moich rad może koledzy którzy zrobili dla siebie panele podzielą się swoimi uwagami.
-
Chciałbym uzupełnić ostatni post.Po zastanowieniu się doszedłem do wniosku,że za 10000zł można się pokusić o zrobienie semipit z LCD.LCD 8,4'' można w Chinach kupić za około 800zł.Można też kupić LCD dla RWR oraz dokupić karty graficzne do pc,lub kupić nowy pc z silnym procesorem.Pozostałe panele zrobić samemu lub kupić w zależności od pozostałej kwoty pieniędzy.Jest to do rozważenia.
-
Po co od razu kokpit?
Na początek wystarczy:
Thrustmaster Hotas Cougar - cena......?
Orczyk, najlepiej do kompletu Thrustmaster - cena.....?
Jak już jesteśmy przy tej firmie to wypada kupić ramki MFD - cena....?
Do ramek można dokupić 2x LCD ( o których wspomniał vito). To wiąże się z dodatkową kartą graficzną.
Dla dopełnienia realizmu Track IR.
Teraz można podliczyć koszt i zastanowić się czy chcemy więcej? Jeśli to wszystko za mało, polecam tą firmę :
http://scsimulations.com/
Takie elementy jak fotel (ACSII), czy kompletną konstrukcję kokpitu można nabyć w formie KIT. Nie wiem czy oferują zmontowaną wersję. Możliwe, że na zamówienie zrobią co trzeba.
Odsyłam do autora (rodak) tej strony- http://www.f-16.eu/ który buduje kokpit z takich właśnie Kitów.
Schody zaczynają się przy panelach, przykładowo ICP- nie spotkałem się z tym elementem kokpitu który jest plug&play. Można zamówić panel z płytką PCB i przełącznikami ( koszt około 400$), do tego jest potrzebna elektronika która nim steruje, czyli kolejne schody.
Są więc dwa wyjścia:
1. Kupić to co wymieniłem wyżej i pozostać w takiej konfiguracji.
2. To co wyżej + reszta budowana w własnym zakresie, bo 10 000zł jak pisał vito wystarczy na mini kokpit.
Generalnie za takie pieniądze można wybudować kokpit, pod jednym warunkiem- trzeba poznać trochę elektroniki, informatyki, stolarki, mechaniki, cierpliwość i zapał ( nie słomiany ;) ) przede wszystkim. :)
Pozdrawiam.
-
Można też podłączyć osobny dotykowy ekran np. 12" (na RS) czasem na aukcjach pojawiają się z 300 - 400 zł i wyświetlać panele lub różne klawisze funkcyjne za pomocą programiku TouchBuddy. Program posiada profile do różnych gier i różnych maszyn. Na pewno miłośnicy LockOna, Falcona, ILa znajdą coś dla siebie. Ekran dotykowy nie jest wymagany, program można obsługiwać myszą ale mimo wszystko polecam dotyk. Osoby ekran można też wykorzystać do wyświetlania zegarów i tak odpowiednio do Falcona mamy F4 Glass, LockOna -> LOVP a do Sturmovika --> UDP (tutaj jednak jest duży spadek FPS i jednak bardziej odpowiednie będzie wykorzystanie osobnego komputera). Druga sprawa to chodzi kokpit stacjonarny czy ruchomy :002:? To co zostanie z 10 000 można też wykorzystać tak :
http://www.acesim.com/ready.html (http://www.acesim.com/ready.html). Gdzieś na forum ktoś podał linka z filmikiem do tego rozwiązania z napędem :banan
-
Nadal ktoś chce kupić gotowy symulator? Proszę bardzo:
http://www.clarksmachine.com/f16c1.html
Pod jednym foto napisane jest "Low Cost Simulator" :001:. Zachęcające?
-
Dziś na Pilots.pl znalazłem gotowy kokpit szesnastki. Wszystkie panele i wskaźniki są atrapami. Łącznie 6000 EUR:
http://www.sklep.pilots.pl/product_info.php/products_id/542 (http://www.sklep.pilots.pl/product_info.php/products_id/542)
-
Witam.
Zastanawiam się, co posiadacze SimOut mają zamiar zrobić z tą płytką? Macie już pomysł? Jakieś uniwersalne panele, a może kokpit?
Dziwna cisza nastała po zakupie płytek i przyznam, że zżera mnie ciekawość jak to wykorzystacie :). Wiem, że Vito użyje w swoim kokpicie, w moim nie znajdzie zastosowania (mam już komplet elektroniki).
Dlatego przysiadłem do Corela i powstaje takie coś:
(http://img375.imageshack.us/img375/1733/atrautopilot.jpg) (http://img375.imageshack.us/i/atrautopilot.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Będzie to uniwersalny autopilot przypominający wyglądem ten z ATR. Wymiary są odpowiednio dopasowane do wyświetlaczy HD44780. Ten na środku to 4X20, na panelach radio 2X8. Chcę zrobić to z ogólnie dostępnych części. Sterowanie SimOut i cokolwiek czym można sterować przyciski, toggle, encodery. Jak ktoś jest zainteresowany to może przyłączyć się do projektu.
Rysunek paneli wyślę do Skalarki. Jak będzie miał czas i wytnie, pokaże foty.
Pytanie do Zajaca, może pomożesz zaprojektować płytkę PCB pod klawiaturę?
pozdrawiam.
-
Brawo EGHI! Właśnie przymierzam się do czegoś podobnego (najpierw dla ATR czyli strzeliłeś w 10). Aczkolwiek chcę to inaczej rozegrać, tzn. na razie bez wyświetlaczy a wszystkie pokrętła i przyciski bardziej upakowane. Dlaczego ? Bo latam tylko w VC+TrackIR, więc widzę co ustawiam na AFCS tylko myszę trzeba wyeliminować.
Dla uniwersalności tego panelu dodałbym kilka innych przycisków jakie można spotkać w Aribus'ach czy Boeing'ach. Choćby FD switch. Panel będzie wtedy kompaktowy, chyba, że plany są na full-real :)
-
W moim nowym projekcie SimOUT będzie odgrywał bardzo ważną rolę.Wstępne założenia opisałem w wątku.
http://www.il2forum.pl/index.php?topic=9985.390
Dodam tylko,że bez tego modułu miałbym problem z projektem PFL zrealizowanym na LCD.Była oczywiście alternatywa realizacji na porcie LPT,ale nie mam tego portu w pc i musiałbym kupić kartę z tym portem.U mnie SimOUT będzie wykorzystany prawie w 100% i będzie realizował prawą strone kokpitu.
Ponieważ jestem zwolennikiem dekompozycji sterowania kokpitu (przyczyn jest kilka)to drugim niezbędnym sterownikiem będzie projekt Damosa.Bez jego projektu musiałbym rozbudować projekt oparty na kartach OC lub kupić kartę Skalarki.Jest to związane z dużą liczbą wejść oraz ograniczeniami SVMappera.
Na koniec chcę zaznaczyć,że gdyby nie było HSC codeking to realizacja kokpitu dla Falcona byłaby możliwa albo za pomocą kart OC przy pomocy FAST alba PHCC przy sofcie Lightning.W tym momencie chcę podziękować codeking za jego projekt.
-
Dziś na Pilots.pl znalazłem gotowy kokpit szesnastki. Wszystkie panele i wskaźniki są atrapami. Łącznie 6000 EUR:
http://www.sklep.pilots.pl/product_info.php/products_id/542 (http://www.sklep.pilots.pl/product_info.php/products_id/542)
Bedzie recenzja niedługo wanny.
-
Witam
Czytam wszystko, ale nie mam czasu odpowiadać, sezon wakacyjny, ale we wszystkich projektach chętnie pomogę. Co do wykorzystania simout to u mnie zbuduje pedestal oraz mcp do 737 wykorzystując simout oraz mjoy / dmjoy :001: /.
pozdrawiam Zając
-
Chwilowy brak czasu ale ja buduje na tych rzeczach 747
-
Dla uniwersalności tego panelu dodałbym kilka innych przycisków jakie można spotkać w Aribus'ach czy Boeing'ach. Choćby FD switch. Panel będzie wtedy kompaktowy, chyba, że plany są na full-real :)
Nie widzę problemu dodać lub przerobić przyciski. Nie planuje full-real, jest duży wybór paneli do Benka, Arbuza, Cessny, czy też uniwersalne niepodobne do niczego ;). Ten który chcę zrobić, też będzie uniwersalny ale niech przypomina wyglądem AP z ATR.
YoYo,
tak z ciekawości... będziesz miał okazję wskoczyć do tej wanny?
-
Witam,
temat powoli stygnie, jedynie vito brnie do przodu. Żeby nie było, że nic się u innych nie dzieje, pokażę nad czym pracuję od jakiegoś czasu.
(http://img163.imageshack.us/img163/4765/p1010838.th.jpg) (http://img163.imageshack.us/i/p1010838.jpg/) (http://img837.imageshack.us/img837/3210/p1010836n.th.jpg) (http://img837.imageshack.us/i/p1010836n.jpg/)
Jest to fuel Gauge do Falcona. Więcej napiszę po pierwszym teście, może jeszcze dziś uda mi się to zrobić.
Pozdrawiam :).
-
Gratulacje EGHI,zrobione jak zwykle profesjonalnie.Może będzie do tego gaugesa skrypt napisany w HSC jako opcja dla tego w SIOC.
-
vito,
tak wiem, obiło mi się o uszy ;). Podoba mi się pomysł, eliminuje Fast.
Jestem po pierwszych testach, udało mi się uruchomić wyświetlacz cyfrowy, podświetlanie, servo też już działają. Nie ma jeszcze wskazówek, ale jestem przekonany, że będą dobrze wskazywać. To zresztą testowaliśmy już kiedyś. Był problem z płytką Skalarki, okazało się, że kabel USB nie może być zbyt długi. Testowałem na 15m, po wymianie na zwykły 1,5m problem zniknął, tutaj wielkie dzięki codekingowi ;).
Można powiedzieć, że mamy kolejny udany projekt. Podziękowania dla Skalarki za wycinanie na laserze skomplikowanych elementów, vito za napisanie skryptu i oczywiście codekingowi za HSC. Dzięki panowie!! :)
Kilka fotek z dzisiejszych testów:
(http://img266.imageshack.us/img266/1746/p1010851g.th.jpg) (http://img266.imageshack.us/i/p1010851g.jpg/) (http://img808.imageshack.us/img808/1903/p1010853k.th.jpg) (http://img808.imageshack.us/i/p1010853k.jpg/) (http://img251.imageshack.us/img251/5899/p1010849y.th.jpg) (http://img251.imageshack.us/i/p1010849y.jpg/)
-
Niezła choinka :) Gratulacje. Konstrukcja pierwsza klasa. Będą dwie wskazówki (są dwa serwa) ? Wskazówki będą podświetlane ?
Jeszcze raz: wygląda rasowo :karpik
-
Tak, są dwa serwa, będą dwie wskazówki. Zasada działania mechanizmu jest podobna jak w zwykłym zegarze. Są dwie osie, jedna cieńsza, miedziana która wchodzi w odpowiednio grubszą. Ta druga jest wykonana celowo z przeźroczystego plastiku, po niej właśnie powędruje światło do podświetlenia wskazówek, coś jak światłowód. Jeszcze nie wiem jak i czy to zadziała ale taki jest plan.
-
Zegar rasowo wyszedł ale na pierwszym zdjęciu widać ciemne plamy tzn. ciemniejsze miejsca. Zapewne to wynik punktowego światła jakie daje dioda, więc proponuję stary patent czyli zmatowić pleksę/poliwęglan tak aby lepiej się światło rozpraszało :).
-
Zegar rasowo wyszedł ale na pierwszym zdjęciu widać ciemne plamy tzn. ciemniejsze miejsca. Zapewne to wynik punktowego światła jakie daje dioda, więc proponuję stary patent czyli zmatowić pleksę/poliwęglan tak aby lepiej się światło rozpraszało :).
Słuszna uwaga, problem podświetlania niby banalny jest największym z którym się borykam ( i nie tylko ja). Ciężko jest równomiernie podświetlić całość. Znam dwa sposoby które dają w miarę dobry efekt:
Oddalenie, jak to tylko możliwe diod od powierzchni podświetlanej, lub zatopienie diod w przeźroczystej plexi. W obu przypadkach często nie ma możliwości realizacji technicznej. Jest jeszcze jeden sposób, naszpikowanie diodami całej powierzchni. Przygotowałem płytkę PCB pod taki wariant i mam możliwość dolutowania jeszcze więcej diodek. Na foto widać ile ich może być, każda dioda oznaczona D1. Teraz jest ich tylko 6, mogę dołożyć jeszcze 7.
(http://img835.imageshack.us/img835/259/p5030806.th.jpg) (http://img835.imageshack.us/i/p5030806.jpg/)
Nie bardzo rozumie z tym matowieniem, zrobić to na tylnej powierzchni tarczy na którą pada światło diody? Dodam, że użyłem najmocniejsze diody jakie znalazłem( 700mcd).
Tak z innej beczki... w innym wątku pisałem o projektorze. Kupiłem, odpaliłem, postawiłem kokpit przed wyświetlanym ekranem i muszę powiedzieć, że podczas robienia beczki może zakręcić się w głowie ;). Inaczej też trzeba reagować, orientacja miedzy przyrządami a horyzontem jest kompletnie inna niż na ekranie monitora. Zamieszczam jedno foto w tym temacie ( stoi tam kokpit, więc chyba mogę tutaj). Jakość zdjęcia fatalna, za co przepraszam. ( kompletne beztalencie fotograficzne)
(http://img185.imageshack.us/img185/2006/p5160821.th.jpg) (http://img185.imageshack.us/i/p5160821.jpg/)
Pozdrawiam.
-
Słuszna uwaga, problem podświetlania niby banalny jest największym z którym się borykam ( i nie tylko ja). Ciężko jest równomiernie podświetlić całość. Znam dwa sposoby które dają w miarę dobry efekt:
Oddalenie, jak to tylko możliwe diod od powierzchni podświetlanej, lub zatopienie diod w przeźroczystej plexi. W obu przypadkach często nie ma możliwości realizacji technicznej.
Musiałbyś poszukać trochę o moddingu komputerów. Tam często właśnie używało się takiego patentu z matowieniem. Spróbuj jedną powierzchnie zmatowić papierem ściernym, jakimś drobnym. Można też zobaczyć co daje lepszy efekt czyli czy dioda podświetlana od tyłu czy delikatnie wsadzona (nawiercasz wiertłem tylko uważaj przy wierceniu najlepiej wolno, powoli i np. podlewając olejem roślinnym) lub też dioda wsadzona w bok plexy.
Ze zmatowieniem zobaczysz jaki efekt będzie lepszy tzn. która strona plexi będzie lepsza jak ją zmatowisz. Najlepiej na jakimś skrawku plexi wypróbuj. Tu fota piaskowanej, matowej plexi:
(http://almega.com.pl/images/led2.jpg)
-
Zrobiłem szybki test z matowieniem plexi i przyznam, że sugestie KosiMazaki są właściwe :). Jest jednak jedno ale.. Zmatowiona powierzchnia idealnie rozprasza światło diody które są umieszczone w nawierconych otworach plexi. Najlepszy efekt, kiedy są wsadzone w bok. Jednak, jeśli promień światła napotka na przeszkodę typu Toggle switch lub inną, poza przeszkodą robi się zaciemnione miejsce. Lekarstwem na to jest naszpikowanie Plexi diodami z każdej strony. Tak zrobiłem budując kiedyś panel MISC, efet był taki:
(http://img237.imageshack.us/img237/1803/p5170404.th.jpg) (http://img237.imageshack.us/i/p5170404.jpg/) (http://img801.imageshack.us/img801/5630/p5210411v.th.jpg) (http://img801.imageshack.us/i/p5210411v.jpg/)
Jak widać, efekt w miarę dobry. Jest to chyba najlepsze rozwiązanie podświetlania paneli z zastosowaniem diod. Oczywiście są lepsze sposoby, bardziej zaawansowane i kosztowne, jak np. to (mata świecąca) - http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=160460831287&ssPageName=ADME:B:EOIBSA:GB:1123 To jednak jest dosyć kosztowne rozwiązanie, gdzie do podświetlenia całego kokpitu trzeba zastosować kilka a może kilkanaście przetworników zasilania. Ja zostaję przy "tradycyjnym" sposobie czyli diody. Tutaj pojawia się kolejny problem, kolor podświetlania. Jak wiadomo, najmocniejsze światło dają diody białe, czego nie można powiedzieć o kolorowych a zwłaszcza zielonych. Długo szukałem odpowiednich i dzięki koledze Skalarki znalazłem odpowiednie. Jednak mimo mocnego światła nie dają idealnie zielonego koloru, można je stosować w bardzo małych elementach, gdzie są skupione na małej powierzchni. Szukając alternatywy wpadłem na zupełnie inny pomysł. Dioda biała daje najmocniejsze światło, trzeba tylko zmienić jego kolor. Idealnym rozwiązaniem stała się folia samoprzylepna, transparentna koloru zielonego. Przykleiłem taką folę od tyłu panela. Dioda biała podświetla płytkę pomocniczą tak samo jak w moim panelu MISC, lecz miedzy warstwami plexi znalazła się ta folia.
(http://img823.imageshack.us/img823/161/p5150816.th.jpg) (http://img823.imageshack.us/i/p5150816.jpg/) (http://img168.imageshack.us/img168/9079/p5150815.th.jpg) (http://img168.imageshack.us/i/p5150815.jpg/)
W takim patencie można stosować dowolne źródło światła białego jak diody, żarówki itp. folia zawsze zmieni kolor.
Wracając do mojego wynalazku Fuel Gauge do Falcona, znalazł się na swoim miejscu. Dolutowałem więcej diod i chyba lepiej to wygląda. Wskazówki jeszcze od prototypu, więc niezbyt efektowne ale nie mogłem się powstrzymać ;).
(http://img824.imageshack.us/img824/4919/p1030868w.th.jpg) (http://img824.imageshack.us/i/p1030868w.jpg/)
Pozdrawiam.
-
Idealnym rozwiązaniem stała się folia samoprzylepna, transparentna koloru zielonego
Potwierdzam,stosuje tę folię w podświetlanych przyciskach oraz wskaźnikach 7segLED.
Co do podświetlania paneli to nadal mam problem.W nowej konstrukcji kokpitu jest więcej miejsca to może oddalenie diod od paneli da lepszy efekt.
Fuel gauges wygląda profesjonalnie,gratulacje.
-
Można spróbować z zielonymi katodami do komputerów. Trzeba by było jedynie poszukać czegoś w rozsądnej cenie.
http://allegro.pl/revoltec-katoda-single-zielona-30-cm-gw-24m-fv-i1227708016.html
W swoim czasie na Allegro można było kupić kable Glansa rodem ze sklepu IKEA. Kosztowało to z 7zł, było elastyczne i nieźle świeciło. Minusem było zasilanie z baterii ale to da się przerobić. Mam w domu dwie sztuki więc mogę cyknąć fotkę - przykładowe:
(http://www.joelogon.com/images_temp/010206elwire400.jpg) (http://farm1.static.flickr.com/60/220493920_8fc66b38c2.jpg)
Można też skontaktować się z firmą Noman (http://www.moman.pl/), która zajmuje się produkcją zegarów indiglo i może by sprzedali trochę tego tworzywa.
-
Ciekawe rozwiązanie,30cm powinno oświetlić cały panel np.LG oraz CMDS lub panele z boków kokpitu.Ciekawe po co ten konwerter zasilany z 12V.Chyba,że redukuje napięcie do mniejszej wartości.
-
Witam.
Niedługo wychodzi DCS A-10.
Chciałbym zrobić panele MFD z matrycami do tego symulatora.
Chodzi o połączenie Thrustmaster MFD (http://benchmarkreviews.com/index.php?option=com_content&task=view&id=7929&Itemid=22) z jakimiś matrycami.
Wiem, że ludzie używają dwóch monitorów Samsunga SyncMaster U70 na USB (http://www.benchmark.pl/aktualnosci/Samsung_SyncMaster_U70_-_kolejny_monitor_USB-16760.html), ale mi chodzi o coś bardziej dopasowanego.
W związku z faktem, że jestem zielony mam parę pytań.
1. Czy można kupić matryce monochromatyczne ( ze sterownikami ), które były by dopasowane do tych MFD, w miarę rozsądnej cenie?
2. Czy trudno napisać do takich matryc sterownik, jak podłączyć to do komputera.
3. W jaki sposób zrealizować przekazanie informacji z kokpitu DCS tak aby na monitorze wyświetlać konkretne rzędne kokpitu?
Proszę o odpowiedź czy jest to w miarę realne przy normalnych środkach finansowych.
-
Ciekawe po co ten konwerter zasilany z 12V.Chyba,że redukuje napięcie do mniejszej wartości.
"Katoda" to lampa wyładowcza bez skrętek. oznacza to że aby spowodować zapłon takiego źródła światła należy przyłożyć do jego elektrod dość spore napięcie rzędu kilkuset Voltów.
Po zapłonie do świecenia wystarczy już niższe napięcie ale nadal jest to rząd setek Voltów.
-
Jaeger dzięki za wyjaśnienia.
RRBM moja rada zapytaj faceta,który buduje DCS-A10,jest pod linkiem
http://www.viperpits.org/smf/index.php?topic=5509.0
Jeśli wpiszesz hasło DCS-A10 na forum vipertpits to będziesz miał wątki gdzie się ten temat przewija.Najlepiej pytać tych co już to zrobili lub robią.
-
Można spróbować z zielonymi katodami do komputerów.
Zastanawiałem się kiedyś nad zastosowaniem, jednak jest podobny problem jak w przypadku maty- ilość przetworników i nie można tego dzielić na mniejsze części.
RRBM,
ramka MFD ma wymiary 14/14cm, nigdzie nie kupisz kwadratowych matryc. Długo szukałem czegoś co można zastosować i znalazłem na Ebay TFT mini monitory. Są to 8 calowe matryce, z wejściem VGA ( to duży plus), o dużej rozdzielczości ( za tą cenę). Po wydłubaniu z obudowy matryce mają 14/18cm, więc 4cm za duże. To jednak nie jest problem w moim i vito przypadku, nadmiar został sprytnie schowany. Paradoksalnie stało się to przydatne w moim kokpicie, na prawej stronie tymczasowo wyświetlam w tym miejscu dwa instrumenty (DED, FUEL).
Jeśli chodzi o wyświetlanie danych MFD na dodatkowym monitorze, to musi być dodatkowy program, który wydobędzie obszar kokpitu z DCS, lub działa samodzielnie, niezależnie, pobierając tylko odpowiednie dane z pamięci współdzielonej lub offsety z DCS ( nie wiem jak działa ten symulator). Dodam, że na YouTube widziałem takie próby, niestety nie potrafię tego odszukać.
-
http://www.youtube.com/watch?v=sMCPnVK_24Q&feature=channel
Sorry, czas edycji minął :).
Co prawda to Black shark, ale ten sam sim.
-
Witam,
chcę wam przedstawić moje ostatnie wypociny zwane Glareshield. Obudowa wykonana z blachy aluminiowej, pomalowana na kolor czarny-mat.
Przy braku odpowiednich narzędzi było to wielkim wyzwaniem. O ile wycinanie blachy o przekroju 1mm nie przysparza większych problemów, wyginanie i profilowanie to wielka sztuka. Jako giętarka posłużyła mi komoda z szufladami :), do profilowania okrągłości rura od odkurzacza ;). Efekt zadowalający jednak, jak wspomniałem łatwo nie było. Zamieściłem tam Indexery, które czekały na instalację w swoim miejscu. Efekt taki:
(http://img46.imageshack.us/img46/1858/p1030859m.th.jpg) (http://img713.imageshack.us/img713/3010/p1030855.th.jpg) (http://img46.imageshack.us/i/p1030859m.jpg/) (http://img28.imageshack.us/img28/347/p1080886l.th.jpg) (http://img28.imageshack.us/i/p1080886l.jpg/) (http://img203.imageshack.us/img203/3046/p1080878w.th.jpg) (http://img203.imageshack.us/i/p1080878w.jpg/) (http://img693.imageshack.us/img693/4538/p1080879b.th.jpg) (http://img693.imageshack.us/i/p1080879b.jpg/)
Pozdrawiam.
-
Gratuluję,mnie nie to czeka w najbliższym czasie.Chcę użyć blachę 0.5mm może wystarczy.
-
Witam,uzupełniam braki w bocznych panelach przed ich połączeniem z kolumną środkową CP.Podłączyłem diody LED podświetlające wskaźniki.Jest ich dosyć dużo.
(http://img704.imageshack.us/img704/7303/mdscn0078.th.jpg) (http://img704.imageshack.us/i/mdscn0078.jpg/) (http://img840.imageshack.us/img840/8755/mdscn0079.th.jpg) (http://img840.imageshack.us/i/mdscn0079.jpg/)
Teraz mam problem z kolorem,prawdopodobnie zastosuję folię transparentną koloru zielonego,którą nalepię na pleksi.Następny problem to przyklejenie tych pleksi (okrągły kształt-zabezpieczenie wskaźników) do obudowy.Jak widać problemy dotyczą głównie spraw związanych z pracami mechanicznymi.
-
Nie wiem na czym trudność w oklejaniu polega ale proponuję folię naklejać na mokra powierzchnie. Najlepiej moczyć takim spryskiwaczem jak do kwiatów lub jak ma płyn do mycia okien i potem szpatułką wodę wyciskać. Taki zabieg pozwala dość swobodnie i co najważniejsze ładnie naklejać folię bez stresu, że powietrze pod tym utknie.
-
Nie wyjaśniłem dokładnie o co mi chodziło.Mam wycięte z pleksi okrągłe osłony zewnętrzne wskaźników.Z folią nie ma problemów.Problemy są związane z zrobieniem ramki dla osłon (z czego jak osadzić pleksi).Kolejny problem to przyklejenie ramki z osłoną do obudowy.
(http://img690.imageshack.us/img690/10/gauges2.th.jpg) (http://img690.imageshack.us/i/gauges2.jpg/) (http://img97.imageshack.us/img97/7279/gaues1.th.jpg) (http://img97.imageshack.us/i/gaues1.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Zrobiłem próbę wycięcia ramki z pojemnika plastikowego w kształcie walca zwężającego się przy zakrętce (coś w rodzaju stożka ).To zawężenie umożliwia wciśnięcie do środka osłony z pleksi.Można ramkę przykleić "kropelką" (klej).Gdyby użyć "kropelę" do przyklejenia pleksi to się klej rozleje na powierzchi osłony.Myślałem o zastosowaniu pociętej dętki rowerowej jako ramki,ale to nie najlepiej wygląda.Mam nadzieję,że teraz przedstawiłem dokładniej swój problem.
-
vito,
najlepszym rozwiązaniem jest zrobić nowe osłony. Do FuelGauge zrobiłem w prosty sposób, jest wycięta odpowiednio plexi z wypustami na wkręty ( problem mocowania z głowy). Na to naklejony pierścień wycięty z 5mm plexi. Oczywiście wszystko trzeba ciąć laserem, ale efekt bardzo dobry. Takim sposobem mam zamiar zrobić osłony do mojego kokpitu, rysunek powędruje do Skalarki, możesz zamówić.
Tak to wygląda przed klejeniem i po malowaniu:
(http://img228.imageshack.us/img228/6027/11111j.th.jpg) (http://img228.imageshack.us/i/11111j.jpg/) (http://img684.imageshack.us/img684/5429/p1090905s.th.jpg) (http://img684.imageshack.us/i/p1090905s.jpg/)
Do klejenia użyj pistolet ( na gorąco), bo chyba takowy posiadasz.
-
W takim razie poczekam na efekt końcowy i zamówię u Skalarki.
-
Witam,nie wiedziałem gdzie umieścić ten temat.W końcu zdecydowałem,że w tym wątku.Mam problem z przepustnicą Cougara.Po zrobieniu modu zauważyłem,że nie mogę osiągnąć max.mocy.Po jej demontażu przebadałem potencjometr oraz mechanikę,która powoduje jego obrót.Potencjometr jest dobry rozwiązanie mechaniczne nienajlepsze.Brakuje na skali około 2000 do osiągnięcia zera.W drugą stronę osiąga pełen zakres trochę wcześniej niż to wynika z ruchu ramienia przepustnicy.Ponieważ wartość minimalna odpowiada pełnej mocy to postanowiłem zmienić połączenia potencjometru oraz w setup ustawić revers.To powinno dać pełną moc (trochę wcześniej niż wynika z ruchu wajchą),ale jest to jakieś rozwiązanie.Jutro to sprawdzę,czy miałem rację.Swoją drogą jestem trochę zdegustowany Cougarem,spodziewalem się solidniejszego wykonania.
(http://img687.imageshack.us/img687/8350/przepustnicat.th.jpg) (http://img687.imageshack.us/i/przepustnicat.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Na zdjęciu widać dodatkowy potencjometr podłączony do sterownika.W ten sposób mogę stwierdzić czy osiągam pełny zakres.
-
A jak łączysz potencjometr z mechaniką jeśli "ząbkami" może warto przesunąć nieco położenie...
-
jeśli "ząbkami" może warto przesunąć nieco położenie
Też o tym myślałem.w końcu odpuściłem.Trochę szkoda na to czasu,ale myślę o modzie.Tutaj jest on opisany
http://www.checksix-forums.com/showthread.php?s=5ad69bad0dab6d9b00c8880f43a8dd30&t=132677&page=2
Zrobienie tego modu wymaga czasu oraz precyzji i to jest mój problem.
-
Precyzja czy czas? :)
Dla mnie to czarna magia (w kontekście języka). Nie zaryzykowałbym walki z taką modyfikacją bez możliwości porządnego zrozumienia tematu...
-
Zastanawiam się nad użyciem 7" monitora na USB w roli Caution Panel oraz Fault Display. Z tego co wyczytałem dla danych niekompresowanych jedna klatka w rozdzielczości 800 x 600 zajmuje 0.45 MB (monitor natywnie działa rozdziałce 800 x 480).Transfer jaki można uzyskać na USB nie przekracza zazwyczaj 35 MB/s. By uzyskać poziom 60 klatek na sekundę, potrzebne będzie więc pasmo o przepustowości 27 MB/s więc prawie maks jaki oferuje USB. W CP i PFD obraz aż tak dynamicznie się nie zmienia więc teoretycznie powinien się płynnie odświeżać. Pozostaje jeszcze obciążenie procesora, które w dwu rdzeniowcach przy roz. 1600 x 1200 przy animacji we flashu dochodzi do 20 %. Tutaj chyba nie dochodziło by do tak karkołomnych wartości ? Ponadto raczej nie zalecane będzie podłączenie monitora do huba USB aby nie współdzielić obciążonego łącza. Wiem, że są karty graficzne na USB ale to jest wydatek na kartę i monitor a jest okazja kupić taki monitorek za 200 zł. Nowe chodzą w granicach 130-140$. Co sądzicie o pomyśle czy warto się w to pchać ?
-
Zastanawiam się nad użyciem 7" monitora na USB w roli Caution Panel oraz Fault Display
Zmiany są niewielkie,obraz jest raczej statyczny.Na viperpits stosują LCD na USB.Możesz to sprawdzić.
-
Mi też wydaje się, że na takie wyświetlanie z olbrzymim zapasem wystarczy 30-40 klatek. Dynamika jak powiedział vito jest dość mizerna wiec musi się udać. Za 200 zł bierz martwił się będziesz później.
-
Zachęcam do obejrzenia strony EGHI http://www.f16pit.dbv.pl/news.php a w szczególności zdjęć z lotów próbnych z wizualizacją na wielkim ekranie.
-
Poczytaj o budowie ekranu w dziale "hangar 7" na aerowinx tam Matt Sheil używa oprogramowania do korekty wielkiego ekranu (7,8 m) żeby po rozciągnięciu i załamaniu geometria się zgadzała.
-
Zna ktoś źródło (sklep internetowy) gdzie można nabyć koła zębate, które bez przeróbek można nałożyć na standardowe potencjometry ?
(http://sklep.avt.pl/photo/product_info/c/a/7/1_ca7ee8f66ae7.jpg)
-
http://www.zebatki.com.pl/
http://rbmodel.pl/main.php?action=products&cat=c_mt
-
zebatki.com.pl znam i tam nie ma odpowiednich, natomiast w tym drugim sklepie są idealne, 6.05mm a potencjometry mają 6mm. Dzięki !
-
Zobacz jeszcze tutaj:
http://www.akcesoria.cnc.info.pl/kola_zebate.htm
-
Tak się zastanawiam nad czym pracujesz Codeking.Mam nadzieję,że jest to związane z silnikami krokowymi.Ja ostatnio spaliłem 2 serwa podłączając odwrotnie zasilanie i teraz czekam za nowymi.
-
Po długiej przerwie wracam do tematu silników krokowych i serwomechanizmów.
-
Przepraszam za być może 'ciekawskie' pytanie ale muszę go zadać.
Czy kokpity które budujecie są oparte o rzeczywiste wymiary kokpitu F-16, czy też to tylko przybliżenia oparte na zdjęciach. ?
Czy są w ogóle dostępne w sieci lub na forum jakieś CAD'o podobne dane na ten temat ?
-
Można kupić dokumentację z wymiarami kokpitu oraz paneli na forum viperpits.Można także zrobić na podstawie inf.na tej stronie http://www.xflight.de/
Ja tak robiłem na początku projektując panele do kokpitu.Teraz kupiłem gotowe panele już wycięte i z grawerką.Można je także kupić na viperpits.
-
Czy kokpity które budujecie są oparte o rzeczywiste wymiary kokpitu F-16, czy też to tylko przybliżenia oparte na zdjęciach. ?
Rzeczywiste wymiary posiada tylko producent :001:. Jak wspomniał vito można kupić dobre projekty, lub gotowe elementy. Jeśli pytasz o Tube, to można kupić projekt w CAD, kosztuje 200$. Ja zrobiłem własny na podstawie setek różnych dokumentów, fotek i innych projektów.
Wymiary są zbliżone do oryginału ale nigdy w domowych warunkach nie odtworzysz idealnie. W zasadzie każdy kokpit (domowy) jest inny, nawet robiony z tego samego projektu. W niektórych miejscach celowe zmiany, np centralną konsolę poszerzyłem o 9mm po to, żeby zmieścić tam bez problemu monitor 10 cali. Takich "niedociągnięć" jest dużo więcej i nie przejmuję się tym, nikt z linijką biegać w koło nie będzie ;).
-
Dzięki z informacje. Myślałem, że może pojawił się w necie jakiś przeciek informacji konstrukcyjnych, a ja go po prostu przegapiłem :002:
Oglądając zdjęcia Waszych kokpitów wydawało mi się że są idealnie podobne do tego co widać na zdjęciach w realu - stąd moje przypuszczenia że oparte były na rysunkach konstrukcyjnych. F-16 był sprzedawany do tak wielu krajów (nie koniecznie dzisiaj przyjaźnie nastawionych do NATO) więc tajemnice typu główne wymiary przestają mieć chyba sens - to przecież nie F-22 czy coś jeszcze nowszego.
Moje zainteresowanie tym tematem pochodzi nie tyle z chęci robienia kokpitu co testu możliwości zrobienia pitu 3D do symulatora.
-
Moje zainteresowanie tym tematem pochodzi nie tyle z chęci robienia kokpitu co testu możliwości zrobienia pitu 3D do symulatora.
Możesz rozwinąć? :)
-
Po prostu kokpit 3D w Falcon AF nie bardzo mi się podoba. Z czystej ciekawości zacząłem myśleć o czymś lepszym - ale nie proszę nie brać tego zbyt poważnie - ot takie sobie przemyślenia :001:.
-
To jak masz takie zdolności może zrobisz coś, żeby wyciągnąć MFD z FalconaAF na dodatkowy monitor bez kombinacji z współrzędnymi X,Y jak w programie MFDExtractor ( Znasz ten program? ). Inaczej mówiąc działanie w 3D.
-
O MFDExtractor chyba kiedyś czytałem i z tego co sobie przypominam działa on na zasadzie podglądu Direct3DSurface na której jest renderowany obraz widziany w 'ekranie MFD'. Pomysł dość ciekawy i w zasadzie optymalny. Problemem być może jest sam sposób realizacji zadawania parametrów do programu. Jednak bez dostępu do źródeł AF'a dość trudno jest wymyślić coś lepszego.
Napisz proszę co najbardziej Ci przeszkadza w MFDExtractor' i co warto by było zmienić ?
-
Trochę nie w temacie rozmowa ale ma to związek z kokpitami więc chyba można. W OF takiego problemu nie ma, wszystko działa kiedy przełączymy na kokpit 3D. Zakładam, że MFDX czerpie dane z SharedMem.., to w przypadku OF. W AF jest dokładnie jak napisałeś, w oknie MFDX widać tylko wydzielony obszar obrazu z kokpitu 2D, kiedy przełączysz na 3D obraz znika, co jest logiczne. Zakładam, że to wina wersji Falcona i chyba nie da się tego zrobić w AF. Pytam dlatego, że w kokpicie (tym fizycznym) który buduje, nie potrzebuje na ekranie nic poza widokiem na horyzont. Gdyby udało się zrobić to w AF, kokpit działał by w dwóch wersjach Falcona. Jeśli chodzi o gaugesy w MFDX, nie ma z tym żadnego problemu, działają w wszystkich wersjach. My zresztą powoli przechodzimy na własnej konstrukcji.
-
Zakładam, że to wina wersji Falcona i chyba nie da się tego zrobić w AF
Ja też tak myślę tym bardziej,że twórca MFDX Lightning to potwierdził.W związku z czym nie ma sensu wyświetlać dla AF MFD w kokpicie 3D.Kokpit fizyczny dla 2D traci sens zarówno dla AF jak i 3D.
Dodatkowo w 3D dla OF usuwamy kokpit na ekranie.Można także usunąć HUD jeśli mamy go zrealizowanego fizycznie.
Nie mam jeszcze zakończonych prac związanych z kokpitem,ale już mogę stwierdzić,że zabawa z symulatorem posiadającym fizyczny kokpit znacznie się różni od symulatora z kokpitem na ekranie.Wprowadzając dodatkowo kilka ekranów można osiągnąć dodatkowe efekty.Co do wymiarów to tutaj moja rada.Jeśli ktoś ma dużą masę ciała to lepiej zrobić większy kokpit.Nie mam jeszcze zamontowanego fotela,ale już trzeba uważać wchodząc do "środka kokpitu".
-
Przepraszam za być może 'ciekawskie' pytanie ale muszę go zadać.
Czy kokpity które budujecie są oparte o rzeczywiste wymiary kokpitu F-16, czy też to tylko przybliżenia oparte na zdjęciach. ?
Czy są w ogóle dostępne w sieci lub na forum jakieś CAD'o podobne dane na ten temat ?
Myślę,że może tutaj znajdziesz informacje.
http://www.viperpits.org/smf/index.php?topic=6737.0;topicseen
-
Panowie mam pytanie za pomocą jakich przewodów łączycie mjoya z przełącznikami. Ja w tej chwili używam parę gniazd BLS 2 pinowych ale zastanawiam się nad np. taśmami do dysków ATA. Czy racjonalniej wpiąć taką taśmę czy też kilka BLSów o różnej ilości pinów ? Wtyk ATA mam jeden pin zaślepiony trzeba bo go rozwiercić. Jak to rozwiązaliście u siebie, będę wdzięczny za wsparcie wypowiedzi przykładami foto :001:
-
Foto nie zrobię, ale ja używam gniazd na goldpiny - pojedyncze, podwójne, 2x2, 2x8 itp. Do tego taśmy przewodów - 8 i 12 żyłowe.
http://www.altron.com.pl/Allegro/ZLkabGOLD_PINkompl2x2.jpg (http://www.altron.com.pl/Allegro/ZLkabGOLD_PINkompl2x2.jpg)
(http://[url=http://www.altron.com.pl/Allegro/ZLkabGOLD_PINkompl2x2.jpg]http://www.altron.com.pl/Allegro/ZLkabGOLD_PINkompl2x2.jpg[/url])
-
Gniazda już dokupiłem, teraz taśmy, czy kupuje się je z metra, czy określone długości na sztuki ? Muszę taka taśmę pociągnąć na odcinku około metra w linii prostej więc pewno wyjdzie grubo ponad metr. Myslałem żeby gdzies po drodze zastosować gniazdo i wtyk tak aby w razie konieczności rozłączenia i wyjęcia panela, pod który taśma mam być podpięta nie wyciągać ponad metrowej długości przewodów z mjoya.
-
Tam gdzie kupuję, te taśmy (żyły różnokolorowe) są na metry - 8 żyłowej mam chyba jeszcze ze 3 metry ;)
20 i 40 żyłowe taśmy IDE też się czasami trafiają w szpulach.
-
Postaram się zobrazować na zdjęciu o co mi dokładnie chodzi. Otóż mjoya mam po lewej stronie kokpitu a taśmy chcę poprowadzić pod lub wokół fotela tak aby zbiegały się na wewnętrznej ściance lewej strony podstawy paneli. Tam chce je zakończyć gniazdami do których będę juz bezpośrednio wtykał BLSy z poszczególnych przełączników. Pytanie jest takie: jakich gniazd najlepiej użyć i w jaki sposób połączyć je z podstawą czyli wewnętrzną ścianą kokpitu. Schemat ideowy poniżej (z Painta :001: )
(http://img401.imageshack.us/img401/8971/clipboardog.th.jpg) (http://imageshack.us/photo/my-images/401/clipboardog.jpg/)
-
Dla tych twórców kokpitów, którzy chcą wykorzystać komputerki "gotowce" do sterowania i/lub wyświetlania na wyświetlaczach dodatkowych informacji - pojawiają się małe i tanie zestawy jak np. Raspberry Pi:
http://gadzetomania.pl/2011/08/30/mikrokomputer-za-80-zlotych
http://www.raspberrypi.org/
Dość sprawny system z Lunuxem na pokładzie. Dla hardcore'ów polecam, stosowane przez znajomych, niektóre routery, które są fajnymi mikrokomputerkami do wielu zastosowań, najczęściej z wrzuconym na to systemem z https://openwrt.org/
Sam używam (używałem) kompów na arm'ie do wyświetlania mapy do Iła oraz do wyświetlania przyrządów z kabinki (odczyt via devicelink), miły dodatek do biurka, szkoda, że nie były obudowane tak pięknie, jak niektóre "realne" simkokpity z tego wątku...
-
Sorbifer możesz coś więcej napisać o tym devicelink'u?
Poszperałem trochę w internecie i widzę, że to jest tylko do Ił'a. Zgadza się?
I z tego co doczytałem to na kompie gdzie są wyświetlane przyrządy, musi być zainstalowany Windows.
A teraz pytanie o Raspberry Pi. Czy na tym procesorze ARM można uruchomić windows'a? Czy tylko linux'a?
Bardzo mi się spodobał ten Raspberry Pi i chętnie bym go wykorzystał do budowy kokpitu na bazie małych komputerów połączonych w lokalnej sieci.
Tylko nie wiem czy ograniczeniem nie będzie system operacyjny (o ile Raspberry Pi pracuje tylko na linux'ie)...?
-
Tak - devicelink jest w użyciu w Ile-2. To prosty (prymitywny) protokół do przekazywania parametrów. Program "odbiorczy" UPDSpeed można uruchamiać z linux'a via Wine, albo samemu napisać odbiornik :) Opis protokołu w każdym zainstalowanym Ile w pliku devicelink.txt. Nie wiem, czy ma sens używanie do innych gier. Ja pewnie będę się starał użyć, ale to tylko z lenistwa - jak mam działające z tym komputerki/wyświetlacze, to chętnie coś z innych gier bym wyświetlał :) Ale czy RoF ma możliwość odczytu parametrów samolotu? Wątpię...
Co do Pi, to tam jest ARM, więc Windows to nie teges, :) Chyba, że przez VirtualBox (sam tak używam Windowsa w pracy). Pojedyncze programy uruchamiasz przez Wine, jak wyżej. A co Ci Linux przeszkadza? System jak system, narzędzi programistycznych - mnóstwo. W najgorszym wypadku programy programy z DOS'a czy Windowsa, z pewnymi ograniczeniami, też się da uruchamiać...
-
Przeszkadzać, nie przeszkadza... nawet powoli uczę się tego systemu :-). I bardzo bym chciał wykorzystać Pi jako komputer podłączony w sieci np. z: DCS'em. FSX lub Falcon'em, do wyświetlania paneli z tych symulatorów. Ale oprogramowanie do wyświetlania paneli z tych symulatorów pracuje chyba tylko na Windwos'ach...
-
Wine na ARMA zdaje się nie ma, więc kicha, przykro mi. A co do tych innych symulatorów - jeśli protokół jest jawny, to samemu coś można zrobić. Sporo pracy, ale satysfakcja gwarantowana :)
-
Witam! Dla twórców kokpitów nowy gadget do użycia / oprogramowania, docelowo lepszy i tańszy niż Raspberry Pi:
http://www.cnx-software.com/2012/05/17/74-usd-allwinner-a10-android-4-0-mini-pc-usbhdmi-stick/
Wyjście HDMI, zasilanie, USB i inne wypasy... i Android na pokładzie, lub co innego (Ubuntu etc).
Albo takie: http://www.cnx-software.com/2011/11/19/turn-your-tv-into-a-computer-with-fxi-technologies-cotton-candy-usb-stick/
-
Wszystko pięknie, ale potencjometrów i enkoderów do tego nie podepniesz, bo ma jedynie USB i HDMI. Nadaje się do sterowania wyświetlaczem (monitor z wejściem HDMI), ale obecnie pracuję z Pandaboard ES (http://pandaboard.org/content/resources/references) (ARMv7 Cortex A9 OMAP4) i koszmarne problemy z HDMI, DVI, przegrzewaniem, stabilnością sterowników itp. dość mocno dają się we znaki.
Stawiając na tym Ubntu zyskuje się jedynie na zużyciu energii oraz gabarytach - pudełko jest małe, Jednak słaby zegar (około 1GHz) i ubogie peryferia tudzież cena (700-1300 PLN) nie napawają optymizmem. Taniej wyjdzie zastosować swój stary PC z Linuxem, który mamy za darmo.
W obu przypadkach trzeba posadzić na tym software, który skomunikuje się z symulatorem i wyświetli co trzeba. I w tym momencie zaczynają się schody - brak możliwości wymiany informacji z symulatorem blokuje rozwiązania. O ile dało by się jakoś zapanować nad symulowaniem radaru (kilka widocznych punktów z atrybutami), to zrobić płynny podgląd z kamery termowzji to większy problem. Tego już się nie da tak łatwo przesłać do innej jednostki (PC/ARM), ponieważ albo będzie to ogromy strumień danych (55Mb/s dla 320x240x30fps), albo host PC, na którym działa symulator będzie musiał poświęcić znaczny czas CPU na encoding strumienia video.