Jump to content

komarkus

Modellers
  • Content Count

    101
  • Joined

  • Last visited

Community Reputation

3 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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ę?
  2. Ja dostaję "Transfer expired". Źródła wziąłeś od OpenTX 2.2.0 ? Mamy już stabilny 2.3.1
  3. 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.
  4. Raczej nikt Ci nic nie podpowie, bo na tym etapie tylko Ty znasz i rozumiesz mechanizm i problem. Możemy tylko kibicować.
  5. Po zmiani Po zmianie nazw plików przydadzą się 😃
  6. 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.
  7. 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)
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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)
  13. 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.
  14. 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.
×
×
  • Create New...