TFT vs/ NAV: pressioni diverse

[Slim_]

Mi capita di gonfiare le gomme dal benzinaio (magari calde), farle un pochino più dure della pressione corretta e poi a freddo a casa sistemare correttamente...
Noto OGNI VOLTA che c'è una differenza di 0,1 bar tra il TFT e il NAV, forse c'è una motivazione ? È solo per curiosità.

[kloontz]

Curioso.
I sensori sono gli stessi, perciò la lettura originale dev'essere per forza identica.

Propendo per una conversione diversa da parte dei due dispositivi dei valori codificati che girano su CAN.

Gesendet von meinem SUZUKI GSX-R 600 K1

[Skipper]

Diverso sistema di arrotondamento al decimo?

[kloontz]

Qualcosa del genere... I valori saranno espressi in esadecimale su base millesimi di bar o roba simile.
Da lì a passare a bar, magari uno arrotonda e l'altro tronca, vai a sapere...

Gesendet von meinem SUZUKI GSX-R 600 K1

[managdalum]

In effetti è strano, visto che il Nav dovrebbe solamente replicare la visualizzazione dei dati che gli arrivano dal tft

[ottoDM]

Inizialmente il TFT riportava due cifre decimali, ricordo che avevo notato la differenza tra i due strumenti ed era dovuta all'arrotondamento. Sul TFT hanno semplicemente "nascosto" il secondo decimale senza nessun arrotondamento, mentre il Nav legge il dato completo, ma lo arrotonda.

[GIGID]

Capitato anche a me
Quindi se la pressione è a 2,66 tft legge 2,6 e Nav arrotonda a 2,7? Giusto ?

E già che ci siamo, come mai il tft ci mette così tanto ad adeguarsi quando le sgonfi o gonfi e sembra quasi andare “a scatti nella lettura come se faticasse a leggere le variazioni di 0,1 ?
Da quando lo uso per regolare la pressione, ovvero arrivo al compressore, spengo la moto con il tastino lasciando il quadro acceso e gonfio/sgonfio le gomme ho notato questo.
Semplice “inerzia” voluta dal progettista per non avere misure ballerine (tipo lancetta del carburante?)


Inviato dal mio iPhone utilizzando Tapatalk

[Skipper]

Originariamente inviata da managdalBronson

In effetti è strano, visto che il Nav dovrebbe solamente replicare la visualizzazione dei dati che gli arrivano dal tft

No, riceve i dati dalla moto separatamente dal Tft.

[kloontz]

Si, @GIGID le misure che vedi sono in qualche modo "mediate" nel tempo e magari i due strumenti prendono anche le letture con periodi diversi, tipo il TFT 1 misura al secondo e il navi 1 ogni 5 s.
Ogni lettura è poi usata per calcolare una media scorrevole (es. media sulle ultime N letture) per mostrare la misura.
Anche N potrebbe essere diverso tra i due strumenti.

Gesendet von meinem SUZUKI GSX-R 600 K1

[Slim_]

Tra tutte le idee, quella del diverso sistema di arrotondamento è quella che mi convince di più. Poi.... chi caxxo lo sa !?

[kloontz]

Stiamo dicendo tutti la stessa cosa, @Slim_

Gesendet von meinem SUZUKI GSX-R 600 K1

[Dfulgo]

...il Nav è posto "più in quota" rispetto al TFT quindi con pressione atmosferica inferiore...

[GIGID]

Ecco … ora proverò a gonfiare/sgonfiare le gomme guardando sia il tft che il Nav … così … per curiosità.

Se non ricordo male anche la temperatura dell’acqua a volte presenta qualche piccola diversità tra tft e Nav


Inviato dal mio iPhone utilizzando Tapatalk

[SuperMarioBros]

...al di là della discrepanza segnalata fra Navy e TFT, vogliamo parlare della "reale" pressione ?
Avevo la segnalazione l'altro giorno, di gomma sgonfia all'anteriore, mi dava "allarme, fermarsi subito" o qualcosa del genere: mi dava 1.5-1.6.

Mi son fermato dal gommista 100 mt più avanti.
Ho misurato ed era 2.1

Come mai ?

[Dfulgo]

..perché il sistema BMW ricalcola la pressione ad una ipotetica temperatura standard, magari dal benzinaio l'aria interna era tipo quanti gradi?

[Maurizio1965]

Originariamente inviata da Slim_

...
Noto OGNI VOLTA che c'è una differenza di 0,1 bar tra il TFT e il NAV, forse c'è una motivazione ?

Anche a me fa così sempre.

Inviato dal mio COL-L29 utilizzando Tapatalk

[managdalum]

Originariamente inviata da Skipper

No, riceve i dati dalla moto separatamente dal Tft.

Non mi sembra una soluzione particolarmente “furba”, ma evidentemente deve essere così.

@supermariobros: c’è un thread che tratta proprio di quell’argomento

[Skipper]

Originariamente inviata da managdalBronson

Non mi sembra una soluzione particolarmente “furba”, ma evidentemente deve essere così.

@supermariobros: c’è un thread che tratta proprio di quell’argomento

Nel senso che lavorano in parallelo non in serie.

[managdalum]

Continuo a pensare che non sia una grande idea

[Skipper]

Originariamente inviata da managdalBronson

Continuo a pensare che non sia una grande idea

Continuo a non capire. Se non volessi il tft o navigatore? Perderei l’informazione? Ma forse non capisco le tue perplessità.

[kloontz]

@managdalBronson: E' l'architettura che è fatta così.

Anche se non sono sicuro quale centralina della moto si interfacci con i sensori ruota, ce ne può essere solo una, che poi pubblica i dati letti sul CAN, a disposizione di altri nodi che la possono usare.

Il modo in cui ogni client visualizza i dati non è (in tutta evidenza) uniforme.

[managdalum]

Originariamente inviata da Skipper

Continuo a non capire. Se non volessi il tft o navigatore? Perderei l’informazione? Ma forse non capisco le tue perplessità.

Nel momento in cui due dispositivi forniscono i medesimi dati riterrei più logico che quello eventuale (nel nostro caso il nav) si limitasse a replicare quelli elaborati dal principale.
Questo proprio per evitare di restituire dati non congrui.
Vedere due strumenti che, sul medesimo parametro, visualizzano dati non perfettamente identici non da una bella impressione, secondo me.
Poi tutto è spiegabile è giustificabile, ma visivamente non mi sembra bello.


@kloontz: penso anche io che sia così, ma, visto che mi sembri centrato sul tema, converrai che due client che elaborano i dati in maniera non identica sia una bruttura.

[kloontz]

Concordo, Manag, ma ricorderai anche che il navi è di Garmin, non di BMW.
Evidentemente gli accordi tecnici tra le parti non sono arrivati a definire il dettaglio di come fare un sprintf()...

RIguardo il fatto di replicare o meno: non esiste un'unità "principale" o "secondario", il dato originale è "grezzo" ed è reso a tutti i nodi client.

[Skipper]

Ecco spiegato il problema. Voi pensate che i due (tft e navigatori) siano l’origine del dato. Invece sono solo due display. Il dato è elaborato dalla centralina della moto. In origine il dato è uno solo, fornito a due display che arrotondano secondo metodologie proprie. In buona sostanza nessuno dei due display nasce per essere un ripetitore dell’altro, pertanto ricevono entrambi lo stesso dato misurato ed elaborato dalla centralina della moto tramite i sensori che sono nei cerchi. Per risolvere il problema i programmatori del Tft e quelli della Garmin, dovrebbero parlarsi e concordare come arrotondare il dato che ricevono dalla moto. Ipotesi del tutto irrealistica e inutile ai fini pratici, oltre che antieconomica.

[managdalum]

Tutto molto chiaro.
Quanto ai rapporti tra i due produttori, a me sembra scontato che se io BMW ti commissiono un apparato a mio marchio, gli fai calcolare un dato, che non sia di pura navigazione, come dico io.
Se non vuoi farlo, piuttosto che avere due dati incongrui, sono io a vedere come tu (Garmin) lo calcoli, e mi adeguo.
Stiamo parlando di poche righe di codice, non mi sembra una cosa così complicata …