Visualizza la versione completa : TFT vs/ NAV: pressioni diverse
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à. https://uploads.tapatalk-cdn.com/20210918/f9211a87c91dc5c8eca23b06174f48fb.jpg
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
Diverso sistema di arrotondamento al decimo?
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
18-09-2021, 08:21
In effetti è strano, visto che il Nav dovrebbe solamente replicare la visualizzazione dei dati che gli arrivano dal tft
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.
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
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.
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
Tra tutte le idee, quella del diverso sistema di arrotondamento è quella che mi convince di più. Poi.... chi caxxo lo sa !? [emoji1][emoji1]
Stiamo dicendo tutti la stessa cosa, @Slim_
Gesendet von meinem SUZUKI GSX-R 600 K1
...il Nav è posto "più in quota" rispetto al TFT quindi con pressione atmosferica inferiore...
:lol:
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
18-09-2021, 10:54
...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 ?
..perché il sistema BMW ricalcola la pressione ad una ipotetica temperatura standard, magari dal benzinaio l'aria interna era tipo quanti gradi?
Maurizio1965
18-09-2021, 14:02
...
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
19-09-2021, 00:24
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 ;)
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
19-09-2021, 11:54
Continuo a pensare che non sia una grande idea
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à.
@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
19-09-2021, 12:09
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.
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.
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
19-09-2021, 14:07
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 …
piegopocopoco
19-09-2021, 16:04
....già!...
Si infatti non ci vorrebbe molto. Ma ci vorrebbe una precisa volontà di bmw.
... ne ho viste di cose in azienda che ti dici "beh che ci vuole a farlo? Adesso chiamo luilà, glielo spiego e vedrai che in breve si sistema..."
... e poi dopo tre anni sono messe come prima ...
Gesendet von meinem SUZUKI GSX-R 600 K1
Una cosa è certa.... da buoni teteski i krukki non cambiano il loro metodo di arrotondamento.
Sicuramente sarà stato richiesto al fornitore, ma se non lo fa sono convinto che esista un motivo. Credo.... [emoji1][emoji1]
Il motivo sembra essere che il fornitore non è più fornitore, visto che sembra che siano passati a collaborare con TomTom
Gesendet von meinem SUZUKI GSX-R 600 K1
Ah.... ecco... Posso dire: "era ora !!" [emoji2369]
il NAV tomtom lo trovo molto meno cervellotico (ma questo è un altro 3ad).
Brein secondo
20-09-2021, 09:41
Purtroppo nelle grandi aziende c'è una dispersione di responsabilità e spesso manca una persona che spontaneamente faccia da garante per la coerenza complessiva.
Questo non è nulla, ho visto cose in banca che se ci penso mi viene il volta stomaco. Migliaia e migliaia di ore uomo sprecate a fare una cosa per anni che poteva essere evitata cambiando un semplice numeretto.
In questo caso il programmatore, che forse non ha mai guidato una moto aveva messo due cifre decimali. Qualche collaudatore l'ha visto e ha fatto notare che era una cagata perchè il secondo decimale, oltre a essere inutile, a rendere memo leggibile il dato quando sei in marcia è anche probabilmente in un ordine di grandezza inferiore alla precisione del sensore che lo rileva e alle variazioni che possono avvenire in pochi minuti di marcia.
Hanno detto all'informatico di togliere il secondo decimale, e l'informatico l'ha tolto come era piu' comodo. Se nel codice gli veniva piu' comodo dare istruzione di visualizzare solo una cifra rispetto a introdurre l'arrtonodmamento avrà fatto cosi', o in buona fede o pensando che nessuno avrebbe avuto modo comunque di verificare e contestare.
Comunque questo strumento serve per avvisarci quando la gomma scende sotto soglia di sicurezza, non usatelo per misurazioni precise.
PS: non solo non ho il navi BMW ma ho tolto anche il supporto che rimontero' solo quando vendero' la moto.
Vedo meglio la strada e non mi sono mai perso lo stesso.
Peterpan.RM
25-09-2021, 09:46
da sempre, succede la stessa cosa anche a me.
sarebbe da rompere le scatole in bmw visto che è tutta roba originale loro
vBulletin® v3.8.4, Copyright ©: 2000-2025, Jelsoft Enterprises Ltd.
Traduzione italiana Team: vBulletin-italia.it |