Jump to content

komarkus

Modellers
  • Content Count

    108
  • Joined

  • Last visited

Everything posted by komarkus

  1. Zaktualizowałem do ACCST v2: X12S, X4R, X8R i S6R - nadajnik z karty SD a odbiorniki z pomocą PC i STK. Poszło gładko. Nawet nie trzeba było ponownie bindować.
  2. Wracając jeszcze do obrazków i dźwięków, dla X10S z FrOS, jest manual u FrSky: https://www.frsky-rc.com/wp-content/uploads/Downloads/Manual/X10-X10S/Manual-X10 X10S.pdf "Model images: The size should be equal or smaller then 50K, 100 is the maximum allowed images in the folder, located in the folder “IMAGE/MODELIMAGES/”. The recommended size is 155x100 (colour: 16bit, RGB 565, 72DPI), smaller images will be displayed in the top left corner, larger images will be cut to fit the available space. Up to 50 characters are available to name the created image file, but 20 is recommended as a maximum in order for it to fit on the menu screens. Track files: located in the folder “SOUNDS/en/TRACK/”. The size should be equal or smaller then 100K, 100 is the maximum allowed images in the folder name length should be less than 10 characters and must have the .wav format." I jeszcze sprostowanie. Wyżej napisałem, że dla RX8R (Pro) jest dostępny ACCESS, na razie nie ma, choć dla RX6R i RX4R jest.
  3. W kwestii "obrazków" w tym dokumencie: https://www.frsky-rc.com/wp-content/uploads/Downloads/HOW TO/FrSky Horus X12 Production System Firmware Flashing Companion 10-29-17.pdf napisano dla FrOS w X12S: "Size 50K or less, max number <100, name length up to 30 chars (.jpg extensions not included), format jpg 155x100 (larger or smaller size will not display as well, cut off, etc.." Z kolei dla dźwięków w https://opentx.gitbooks.io/manual-for-opentx-2-2/content/advanced/audio.html napisano: "Audio File Format File Name: 123456.wav (up to 6 characters plus .wav) Sample Rate: 32 kHz (or 16 Khz, 8Khz) Bits / Sample: 16 (or 8 ) Tracks: 1, mono Compression Codec: PCM (or u-law, a-law)" Co do problemów z bindowaniem po upgrade, upewnij się, że masz kompatybilne wersje firmware w nadajniku i odbiorniku. Opisy plików firmware są niejednoznaczne. Wersja "światowa" może być opisana jako FCC albo jako NEU (No EU), a europejska jako EU, LBT, EU-LBT, można się łatwo pomylić. Dodatkowo Twój RX8R ma dostępne firmware dla ACCST jak i ACCESS, jeśli z rozpędu wybrałeś to drugie, to nie zbindujesz się z X10S (zakładam, że nie montowałeś "kitu" rozszerzającego). Dalej, jeśli pomieszasz ACCST z ACCST v2, też nie zbindujesz. PS. Dlaczego wybrałeś FCC a nie wersję europejską?
  4. Osobiście bardzo się cieszę, że firma na którą postawiłem sprzętowo, nie śpi, rozwija się, poprawia dobre produkty na jeszcze lepsze. Myślę, że ACCST D16 v2 powinien nas błyskawicznie opanować bez marudzenia. Ale ... W zeszłym roku pojawił ACCESS - rozwiązanie technologicznie bardziej zaawansowane od ACCST również v2. Nowe odbiorniki (np. G-RX6, G-RX8, R-XSR, R-X4R) mogą być flaszowane na oba standardy. A nadajniki (droższa część naszej zabawy) muszą być modelami 2019 (X-Lite Pro/S, X10/S Express, X9DP/SE 2019) lub "kitowane" X10, X10S. A mój dylemat jest taki: Czy jest szansa na pojawienie się modułów zewnętrznych z ACCESS (lub "kitów") do starszych nadajników? Kupując kolejne odbiorniki wylałbym wiedzieć.
  5. Widać, że napięcie ma wpływ. Ja bym potestował zachowanie samego Taranisa, a potem razem z modułem. Będą jakieś wnioski. Potem przyjrzałbym się winowajcy po zdjęciu obudowy. Częsty problem, to nie trzymanie parametrów przez kondensatory elektrolityczne. Czasem puchną - co widać, czasem nie, ale pomierzyć można zawsze. Tutaj sporo zależy od Ciebie, na ile elektronika to Twój "brat". Jak użyjesz niższego napięcia zasilania, wszystko może działać długo i bezproblemowo, i to bez wnikania w szczegóły. Ja bym tak zrobił (w drugiej kolejności :).
  6. Spróbuj zasilić nadajnik niższym napięciem, tak 7-10 V. Moduł Crossfire micro TX ma przepisowo 3,5-13 V. Być może, że zasilanie dla niego 3s (max 12,6 V) jest na krawędzi albo już poza. Któryś element modułu TX (np. kondensator filtrujący zasilanie) może mieć już parametry gorsze od znamionowych i nie wytrzymuje, albo i już "poległ" od nadmiaru napięcia.
  7. Sprawdziłem na Ubuntu 19.10 live (z płyty DVD). Companion22 nie startuje, żąda libQt5Multimedia.so.5
  8. Drugi link jest OK. Ale ja na razie poległem. Mam zainstalowany Ubuntu 18.04 LTS. Wywala mi którąś bibliotekę, po najnowszych aktualizacjach mam 2.27, a companion żąda 2.29. Nie chcę zmieniać LTS na wersję "zwykłą" 19.10. Szkoda, że źródła companion wziąłeś nieświeże, a kompilowałeś na najnowszym Ubu. To potencjalne problemy. Pokombinuję jeszcze, może spróbuję na 19.10 live. Na virtualnej maszynie nigdy nie robiłem. A ktoś dał radę?
  9. Ja dostaję "Transfer expired". Źródła wziąłeś od OpenTX 2.2.0 ? Mamy już stabilny 2.3.1
  10. No właśnie. Jeśli masz już wersję beta, udostępnij. Będziemy testować. Dobrze by było, o ile to możliwe, abyś zrobił kompilację pod Windowsa, byłoby dużo łatwiej.
  11. Raczej nikt Ci nic nie podpowie, bo na tym etapie tylko Ty znasz i rozumiesz mechanizm i problem. Możemy tylko kibicować.
  12. Po zmiani Po zmianie nazw plików przydadzą się 😃
  13. Tym się nie martw. To wynika prawdopodobnie z ustawień sensora GPS. Tam we właściwościach można ustawić offset na określoną wartość albo auto offset, to się wyrówna.
  14. Brzmi to rozsądnie. Na mojej przerobionej mapie dźwięków akurat odczyt woltów i metrów działa dobrze, również dla 1,1 wolta. Stara mapa miała volt0.wav volt1.wav volt2.wav - jak u Ciebie. Natomiast "wolta" jest umieszczone w 0163.wav . Podobnie jest z metrami i innymi jednostkami, np.: 0167.wav - ampera 0179.wav - metra na sekundę 0195.wav - metra Z tego wynika, że wystąpienie tej formy odmiany jest chyba jakoś magicznie wyliczane - nie potrafię tego wywnioskować z kodu źródłowego. Ktoś już kiedyś nad tym główkował i to stworzył (kolega Drewniak). Być może jest tam głęboka myśl. Przy Twoich założeniach konwencja działania będzie inna. A co będzie z metrami, amperami itd. Dla każdej jednostki będziesz dodawał osobne procedury tworzenia? Nie rozrośnie się to ponad miarę? Dla 1,1 wolta chyba można zrobić to samo co dla "1 wolt" - dla wartości: wartość = 1.1 odczytaj volt3.wav (wolta)
  15. Skąd taki wniosek? " .... decyduje człon ułamkowy, nie zaś – liczebnik główny ..." Jeśli występuje ułamek, zawsze będzie forma wolta, metra, kilograma itd. (0,9 wolta, 1,1 wolta, 1,3 wolta, 55,9 wolta ...). A dla całych: 0 woltów, 1 wolt, 2-4 wolty, 5-9 woltów, 10-21 woltów, 22-24 wolty, 25-31 woltów, 32-34 wolty ..... Nie potrafię podpowiedzieć. Tu pojawia się kolejny dylemat dotyczący konwencji tworzenia komunikatów. Dlatego wcześniej pisałem o potrzebie rozpracowania "idei" tworzenia komunikatów w oryginale i dopiero potem wypracowaniu poprawek lub stworzeniu algorytmu na nowo. Metoda łatek na kolejne problemy spowoduje, że łatki zaczną zachodzić na siebie, a każda w innej konwencji. Bez "systemu" w postaci algorytmu trudno będzie zapanować nad efektem końcowym. Być może dotychczasowy tts_pl.cpp jest całkiem dobry i wymaga niedużych korekt. Musisz też pamiętać o "mapie" dźwięków, to jest mocno powiązane i błędy mogą wynikać z mapy. Problem obecnie błędnego działania komunikatów po części wynika z tego, że mapa dźwięków pl powstała kilka lat temu, a potem dokonywano zmian w konwencji tworzenia komunikatów, i nowa procedura trafia na starą mapę. Stąd pojawiają się błędy typu "dwie i osiem wolta". We wcześniejszych postach pisałem o moich walkach z mapą dźwięków, ale to było działanie "od tyłu". Trochę się udało poprawić jakość komunikatów. Ale mapa musi współgrać z algorytmem tworzenia. Ja nie potrafię z pliku źródłowego rozrysować algorytmu. A od tego warto by zacząć. Problem stałby się przyjazny i przeźroczysty, więcej osób mogłoby się włączyć w analizę i główkowanie nad systemowym rozwiązaniem problemu.
  16. Zagoolowałem i znalazłem, ze słownika poprawnej polszczyzny PWN: "W liczebnikach wielowyrazowych, złożonych z liczebnika głównego i ułamkowego, o formie składniowej określenia rzeczownikowego decyduje człon ułamkowy, nie zaś – liczebnik główny, np. Przyniosłam dwa i trzy czwarte kilograma truskawek (nie: *…dwa i trzy czwarte kilogramy); Przebywał na placówce tylko trzy i pół miesiąca (nie: *trzy i pół miesiące); Samolot spóźnił się aż sześć i pół godziny (nie: *sześć i pół godzin). " "Liczebniki ułamkowe wymagają określenia rzeczownikowego w dopełniaczu; najczęściej jest to dopełniacz liczby pojedynczej. " Wiec wszystko z poprzedniego mojego postu jest aktualne - 3,1 wolta, 15,8 ampera, 99,5 metra, 6,79 procenta.
  17. Faktycznie, w komunikatach jest maksymalnie tylko jedno miejsce po przecinku, pomimo, że na wyświetlaczu i w logach zapis np. Cells ma dwa miejsca po przecinku. To jest OK. Ale dalej już nie. W ułamkach będzie raczej zawsze "wolta" 1,1 V - jeden przecinek jeden wolta 1,5 V - jeden przecinek pięć wolta 5,1 V - pięć przecinek jeden wolta Wolty odmieniają się tak samo jak np. kilogramy, metry, procenty. Uszy mnie bolały, gdy po wyborach zacny człowiek czytał w telewizorze wyniki i po liczbie dodawał "procent" (28 procent, 6,78 procent). Generalnie jednostki miary się odmienia, ale jak jest ułamek, to jest: wolta, metra, procenta, kilograma. Myślę, że śp. Bielicka dobrze mnie uczyła. W mojej poprzerabianej wersji sounds to wolty akurat działały raczej dobrze. Nie pamiętam za bardzo, co zmieniałem.
  18. Skoro ogarniasz ten temat, to super. Jak będziesz miał wersję beta, udostępnij, przetestujemy. Dziesiętne są niezbędne dla woltów i wskazane dla amperów, metrów, metrów na sekundę, chyba tyle. Ostatnio dla wysokości zmieniłem precyzję czujnika do pełnych metrów, bo wkurzały mnie błędnie komunikowane dziesiąte części. Okazało się, że tak jest lepiej i nie potrzebuję dziesiątych, ale domyślnie jest "0.0". Z kolei wolty (np. pakiet napędowy) nie zaszkodzi domyślna precyzja do setnych wolta.
  19. No to mnie zażyłeś, byłem w mylnym błędzie, myślałem, że podpasowujesz dźwięki do mapy. A tu się szykuje poważna sprawa z tts_pl.cpp. Brawo. Kibicuję. Trochę zastanawiałem się nad problemem, mam przemyślenia, ale ostatecznie uznałem, że to ponad moje siły. Z tego co napisałeś wnioskuję, że dokonujesz poprawek w kodzie źródłowym na zasadzie korekt ad-hoc. Jeśli tak, mam wątpliwość, czy uda się to połatać do stanu w pełni poprawnego, i ciągle będzie coś nie tak. Nie uznaj tego za krytykę, ale jako wkład do dyskusji. Moim zdaniem lepiej by było podejść metodycznie. Przeanalizować działanie kodu, nakreślić użyty algorytm tworzenia komunikatów, sprawdzić gdzie gramatyka się wysypuje, rozbudować/przebudować algorytm i potem zakodować. Nasza gramatyka jest złożona i kluczem jest dobry algorytm. Co sądzisz? Wybiegam za daleko? Jak to robisz i sprawdzasz działanie? Kompilujesz na nowo firmware z poprawionym tts_pl.cpp ? PS. jeden przecinek jeden wolta, jeden wolt, dwa wolty, pięć woltów dB (RSSI) ma ID 25 (ale ostatnio coś jest grzebane z ID czujników, chyba niebawem zmieni się konwencja)
  20. Raczej nie uda Ci się zrobić odczytu w pełni poprawnego, musisz pójść na kompromisy. A takie kompromisy znajdziesz we wcześniejszych postach. Szkoda czasu. Trzeba rozpracować i poprawić gramatykę pl w "tts_pl.cpp" i do tego dopasować mapę dźwięków. To nie byłby zmarnowany czas. Ale chętnych/potrafiących aktualnie brak.
  21. komarkus

    Taranis X9D+ S2

    To jeszcze nie przetestowałeś?! Powinno zadziałać w układzie tak jak piszesz. W X8R nic nie poustawiasz, za wyjątkiem mapowania kanałów (bindowanie ze zworką). W takim układzie jak u Ciebie - nic nie trzeba ponad ustawienia domyślne odbiornika.
  22. komarkus

    Taranis X9D+ S2

    Edit: Tak myślę, że powyżej zagmatwałem sprawę. Przecież SBUS w X8R jest podawany na osobne gniazdo, a kanały PWM są jakby "zrównoleglone" z tymi z SBUS. Więc wystarczy kanał np. 8-smy przeznaczyć dla modułu oświetlenia (i podłączyć moduł do CH8) i nie wykorzystywać tego kanału w kontrolerze modelu. Jego istnienie w sygnale SBUS nie będzie miało znaczenia.
  23. komarkus

    Taranis X9D+ S2

    Miałem podobny problem w hexa - kanały do Naza poszły po CPPM, a podwozie potrzebowało zwykłego kanału PWM. Wykorzystałem odbiornik X4R, on taką potrzebę potrafi zrealizować. Wystarczy bindować ze zworką na CH2-CH3, wtedy uzyskujemy 8 kanałów CPPM (1-8) na wyjściu CH1 i trzy zwykłe kanały PWM (9-11) na wyjściach CH2-4. W X8R tak się nie da, wg mojej wiedzy. Możesz zastosować FrSky SD1 SBUS dekoder albo FrSky dekoder SBUS/CPPM. One potrafią wydzielić zwykły kanał PWM z SBUS-a. Nie robiłem praktycznie, więc szczegółów nie podpowiem.
  24. PS. Uprzedzając, plik powitalny na SD: SOUNDS\pl\SYSTEM\hello.wav
×
×
  • Create New...