Sugestie dot. kolejnych aktualizacji

[ArT]

Szczerze to wątpie.. moim zdaniem ogólnie to nie ma sensu poza jednym przypadkiem dla niskich wartości, np. zużycie paliwa 12,3 ale dla wartości <10 już typu 7,89 ale zakładając nawet 1% dokładności pomiaru to nie bardzo widzę sens wskazań do dwóch miejsc po przecinku.

[przemko]

Będzie możliwość pokazywania danych (spalanie, pozostała ilość paliwa, etc) z dokładnością do dwóch miejsc po przecinku?

Widzę, że kolejna osoba odczuwa pewne ograniczenie związane z zaokrągleniem do jednego miejsca po przecinku (sam też sugerowałem to jakiś czas temu tutaj )

zakładając nawet 1% dokładności pomiaru to nie bardzo widzę sens wskazań do dwóch miejsc po przecinku.

Brak wskazań do dwóch miejsc po przecinku dla wartości mniejszych od 10 powoduje, że bardzo dokładny pomiar jakim dysponuje UKP jest niedostępny dla użytkownika podczas jazdy lub logach tworzonych przez UKP-PRO.

Obecnie ten dokładny pomiar jest używany tylko do określenia ilości pozostałego paliwa w zbiorniku. Dla pozostałych przypadków:
* tuning (wpływ modyfikacji w samochodzie na zużycie paliwa)
* eko jazda (dobór odpowiedniego stylu jazdy, wybieranie najbardziej ekonomicznych tras)

dokładność pokazywana przez UKP jest niewystarczająca.

Dlaczego?

Na biegu jałowym pokazywana jest wartość na wyświetlaczu 0,6 l/h. Co oznacza, że UKP obliczył wartość z zakresu od 0,5500 do 0,6499. Wyświetlona wartość obarczona jest błędem +-8,32%. W specyficznych sytuacjach dla powyższego przypadku UKP nie będzie nawet w stanie odnotować zmiany o 16,5%, co jest stanowczo za dużo aby używać UKP jako narzędzia pomiarowego do sprawdzania wpływu zrobionych modyfikacji w samochodzie na zużycie paliwa.

Jeśli wynik będzie zaokrąglany do 2 miejsc po przecinku to wyświetlona wartość 0,60 l/h obarczona będzie błędem +- 0,82%. Taka dokładność już pozwoli na weryfikację czy dana modyfikacja ma rację bytu czy też nie.

Większe problemy pojawiają się przy próbie porównywania ekonomiczności dwóch tras ma podstawie ekranu podsumowania podróży. W mieście dla dystansów około 6 km auto może spalić około 0.5 litra. Przy zaokrągleniu do 1 miejsca po przecinku ilości zużytego paliwa, rozbieżność między trasą na której zużyło się 0.5 litra a drugą, gdzie zużycie wyniosło 0.6 litra wynosi od 0,0001 (0.1% z 0.1) do 0,1999 (199,9% z 0.1). Wskazania obarczone są błędem +-99,95%. Co uniemożliwia jakiekolwiek sensowne wykorzystanie podsumowania podróży do wyboru najbardziej ekonomicznej trasy.

W przypadku kiedy wartość będzie zaokrąglona do dwóch miejsc po przecinku, rozbieżność wyniesie od 0,0901 (90,1% z 0.1) do 0,1099 (109,9% z 0.1), czyli wskazanie będzie obarczone błędem +-9,9%.

Troszkę dziwi mnie to, że z jednej strony, są w instrukcji wskazówki oraz został naszykowany w programie bardzo fajny asystent który umożliwia uzyskanie dokładności poniżej 1%, a z drugiej strony końcowy wynik jest przedstawiany w tak fatalnym zaokrągleniu który niweczy wcześniej uzyskaną jakość pomiarów .

[ArT]

Przyjąłeś skrajny przypadek spalania chwilowego na biegu jałowym 0,6l/h, które tak naprawdę to nie jest 0,60 l/h tylko jest pływające (sterownik cały czas koryguje dawki, obroty cały czas oscylują +/- kilkanaście rpm) - przy dwóch liczbach po przecinku wskazania na ekranie by cały czas pływały przez co moim zdaniem ucierpiała by czytelność. Przy wartościach rzędu 10+ (dystanse, temperatury, zużycie paliwa itd.) 0,1 to jest właśnie 1%. Przy krótkich trasach i pomiarach z małych jednostek czasowych jest tyle innych zmiennych że nawet jak nie zrobisz żadnej modyfikacji to będziesz miał różne wyniki spalania - silnik będzie się rozgrzewał od 3 stopnie niższej temperatury, na jednych światłach postoisz dłużej o 30 sekund, wiatr będzie 20km/h zamiast 10km/h, północny zamiast południowy itp. itd. Obecnie w UKP z wyższą rozdzielczością (1,23) są wskazania lambda - i one mają sens bo wartość lambda oscyluje zawsze w okolicy jedności i nigdy nie przyjmuje wartości o rząd wielkości wyższych. Z drugiej strony pomiar EGT ma 0 miejsc po przecinku bo są to wartości kilkaset stopni a w pikach nawet 1000+. Są też wskazania adaptacyjne, np. ciśnienie paliwa - dla wartości <100bar jest 1 miejsce po przecinku a dla >100 bar (do 2000bar w dieslach CR) jest 0 miejsc po przecinku. Także w tej chwili jest zrobione w taki sposób, który uznaliśmy za wystarczający i jednocześnie najczytelniejszy na ekranie.

Rozumiem, że będą osoby które będę miały inne zdanie. Sugestia trafia na listę zadań do zrobienia. Tam gdzie będzie miejsce na wyświetlanie może się pojawią 2 cyfry po przecinku. Ewentualnie tylko w data loggerze. Zobaczymy jeszcze jakie będą możliwości, muszę to przedyskutować.

[przemko]

Moja prośba dotyczy tylko wyświetlania dla chwilowego zużycia paliwa, średniego zużycia paliwa. Ekran podsumowania podróży też mógłby zawierać zaokrąglenia do 2-3 miejsca po przecinku. Do pozostałych parametrów nie mam żadnych zastrzeżeń.

Nie wiem dokładnie jak duże mogą być oscylacje dla zużytego paliwa na biegu jałowym, ale przypuszczam, że mogą wynosić około 10%.

0,6 l/h +- 5% spowoduje że otrzymam pływający wynik w zakresie 0,57 do 0,63 l/h. W przypadku modyfikacji która obniży zużycie paliwa już o 2% to uzyskam na wyświetlaczu UKP 0,59 +- 5% czyli oscylację w zakresie od 0,56 do 0,62. Jak widzisz rozszerzenie dokładności do 2 miejsc po przecinku sprawi że UKP będzie wstanie pokazać że dana modyfikacja coś poprawiła. Weź pod uwagę, że przy liczeniu zużycia paliwa w l/h właściwie jest jakaś tam stała razy czas pracy wtryskiwaczy, co powoduje, że UKP jest bardzo czuły na jakiekolwiek zmiany w zużyciu paliwa.

przy dwóch liczbach po przecinku wskazania na ekranie by cały czas pływały przez co moim zdaniem ucierpiała by
czytelność.

Rozumiem to, że niektórzy chcą mieć czytelne dane na wyświetlaczu, dlatego też, można dodać konfigurację która włączy bądź wyłączy zaokrąglanie średniego oraz chwilowego zużycia paliwa do dwóch miejsc po przecinku dla wartości mniejszych od 10. Podobnie jak to już jest dla inteligentnego pomiaru temperatury zewnętrznej.

Przy krótkich trasach i pomiarach z małych jednostek czasowych jest tyle innych zmiennych że nawet jak nie zrobisz żadnej modyfikacji to będziesz miał różne wyniki spalania - silnik będzie się rozgrzewał od 3 stopnie niższej temperatury, na jednych światłach postoisz dłużej o 30 sekund, wiatr będzie 20km/h zamiast 10km/h, północny zamiast południowy itp. itd.

Dlatego też tym bardziej zależy mi na wynikach zaokrąglonych do dwóch miejsc po przecinku dla chwilowego zużycia paliwa. Zwłaszcza dla sytuacji kiedy auto stoi a silnik chodzi na jałowym biegu, bo wtedy większość parametrów jest pod kontrolą.


Co do data loggera.
Jeżeli zapisywane dane były by niezależne od danych wyświetlanych to tutaj można by się pokusić o 3-4 miejsc po przecinku.
Najlepiej jakby dało się uzyskać dokładnie to co obliczył UKP bez żadnych zaokrągleń.

Mam wrażenie, że data logger zapisuje dane końcowe które są pokazywane na wyświetlaczu. Można by też w przyszłości zastanowić się nad zmianą sposobu zapisywania danych. W pamięci flash UKP zapisywać dane przed przeliczeniami. Np. ilość impulsów z wtryskiwaczy, ilość impulsów dla drogi, bezpośredni wynik otrzymany z układów ADC.
Aplikacja UKP zainstalowana na PC przeliczała by "surowe" dane na postać zrozumiałą i oczekiwaną przez ludzi.
Np. wynik otrzymany z układu ADC byłby na PC przeliczany na napięcie a później z niego wyliczane konkretne wartości fizyczne.
Powinno to dać dłuższy czas logowania przy takim samym użytym buforze, rozwiązało by problem zaokrągleń, ponad to dało by możliwość wyboru jednostek fizycznych. Użytkownik mógłby sobie wyeksportować te same dane zarówno w stopniach Celsjusza lub Fahrenheita, ciśnienie w barach czy też w funtach na cal kwadratowy (PSI), w zależności od potrzeb.

Ciesze się i dziękuję, że zamierzacie pochylić się nad tą sprawą.

[ArT]

Nie wiem skąd takie Twoje założenia, ale nie będę z nimi polemizował

Zobrazuje sytuacje dlaczego to nie jest takie proste jak się wydaje. W celu optymalizacji gdzie to tylko możliwe (np. wyświetlanie na potrzeby GUI) obliczeń nie dokonuje się na liczbach zmiennoprzecinkowych tylko na całkowitych. Np. wiele wartości zamiast traktować jako liczbę zmienno przecinkową (która zajmuje więcej pamięci i dla których obliczenia są znacznie wolniejsze - zamiast kilku taktów procesora potrzebne jest kilkanaście lub kilkadziesiąt a czasem i kilkaset) zapisuje się w pamięci jako liczbę całkowitą - w zależności od zakresu 8-, 16- lub 32-bitową (np. liczba 123,4 to w pamięci liczba całkowita 1234). Dopiero podczas wyświetlania oddziela się część całkowitą i część ułamkową. Dodając kolejną liczbę znaczącą nagle okazuje się że nie mieścimy się w założonym obszarze pamięci ani czasu wykonania sekwencji. Obecnie oprogramowanie UKP jest już bardzo dojrzałe - z wersji na wersje coraz bardziej optymalizowane aby zwolnić miejsce na nowe funkcje i obliczenia. Większość krytycznych obliczeń musi być wykonywana w przerwaniach w bardzo krótkim czasie rzędu 0,1ms. Dwie ostatnie aktualizacje to wielogodzinna walka nad optymalizacją. Każda kolejna zmiana i dodatkowa funkcjonalność musi być kompatybilna ze wszystkimi poprzednimi - dodajesz lub zmieniasz sposób obliczeń w przerwaniu a później trzeba przeprowadzić szereg czasochłonnych testów aby mieć pewność że zawsze i wszędzie jedne obliczenia zdążą być wykonane przed kolejnymi. Niestety ale wszystkie operacje związane z GUI są jedne z najbardziej zasobożernych. Także z punktu widzenia użytkownika to jest 1 niewinna cyfra, a z punktu widzenia programisty to jest optymalizacyjny horror Pominę już kwestie że w wielu miejscach 2 cyfry po przecinku się zwyczajnie nie zmieszczą na ekranie bez reorganizacji całego GUI.

[WreX]

Odnośnie dokładności do 2 zer po przecinku podpisuje sie rekami i nogami. A zeby "czytelnosc" nie ucierpiała to najlepiej dac wybor w menu opcji czy wartości maja byc do 1 czy 2 zer i tyle
Jeszcze do pomiarów spalania dorzuciłbym voltomierz do 2 zer po przecinku. No nic czekam na update z nadzieją ze sie uda to dodac.

[Leetveen]

Nie mam pewnosci czy temat byl juz poruszany, ale nie znalazlem skojarzen w szukajce wiec.. chodzi o kwestie obliczania sredniego spalania uwzgledniajaca grzanie silnika na postoju gdy predkosc wynosi zero. Mysle ze nalezaloby wprowadzic dodatkowe algorytmy ktore beda omijaly spalanie paliwa podczas postoju dluzszego niz np 30sek. (ewentualne wprowadzana inna wartosc w ustawieniach). Moznaby sie pokusic o dodatkowa zsumowana wartosc ktora bylaby gdzies wyswietlana i pokazywalaby ilosc spalonego paliwa na postoju do momentu skasowania (np. na ekranie trip). Fajnie ze UKP liczy rzeczywiste spalanie ubywajacego paliwa, ale w moim przypadku z 15l/100 zrobilo sie po 15min postoju 20l/100 i troche to meczy oko , pozostale wyliczenia (ilosc paliwa w baku oraz zasieg na paliwie w baku) powinny uwzgledniac calkowite spalone paliwo jak to sie teraz odbywa.

[tinuviel]

Taka sugestia/prośba:

Ostrzeżenie o ciśnieniu oleju:
- Została jakiś czas temu dodana opcja dzięki której można alert wyciszyć jeżeli napięcie zasilania jest mniejsze niż X. Jako-tako można tego użyć do detekcji czy auto jest odpalone czy nie, ale nie łatwiej i lepiej byłoby to określać po tym czy leci sygnał z wtryskiwacza czy nie? Jeżeli auto jest odpalone to jest, jak nie - to nie ma, wtedy zanim UKP uruchomi alert o niskim ciśnieniu oleju niech wpierw sprawdzi czy ma sygnał z wtrysku - jeżeli nie to znaczy że auto jest zgaszone.

Nie wiem tylko jak to ma się do sytuacji gdy auto jedzie bez gazu na biegu - np. z górki, nie wiem czy wtedy wtryskiwacz daje jakiś znaki życia czy nie

Alternatywnie można by to oprzeć o RPM. Jeżeli RPM>0 to znaczy że auto jest odpalone i alarm działa, jeżelni RPM==0 to jest zgaszone i alert nie ma się odpalać.

[ArT]

@Wrex - 2 miejsca po przecinku pojawiły się w aplikacji android
@Leetveen - czy dobrze rozumiem że chcesz aby UKP fałszował pomiar tylko po to aby kierowca miał lepsze samopoczucie?
@tinuviel - była już dyskusja w tym temacie i wyszło że wiele osób korzysta z pomiarów ciśnienia oleju nie podłączając nawet zużycia paliwa czy RPM, dlatego zdecydowaliśmy się aktywować/dezaktywować alert w oparciu o próg napięcia ładowania co jest uniwersalne i zdaje egzamin

[Leetveen]

Nie wiem czy zglaszal to ktos wczesniej ale ja traktuje to jako "bug" - po przekroczeniu ustawionego terminu alertu (OC) licznik dni zaczal liczyc do przodu, moze fajnie by bylo dorobic ustawienie by w takim przypadku termin po prostu odliczal do nastepnego roku?