georgee

Smith, amit utoljára feltöltöttél auto tripes programot Te készítetted? Lenne pár dolog, amit érdemes lenne módosítani. Csak segítségre van szükségem

Köszönöm, megnézem hátha. Nekem a téli kisebb. 

Üdv Mindenkinek!

195/65 R15-ös gumiabroncshoz milyen értéket használtok a fatorDist-hez?  Téli gumi esetén, ami eredetileg benne van, az az érték 2-4km tévedést mutat 500km-en, viszont amióta fent van a nyári gumi 240km van most a kilométer órámon, a TID-en meg 168km. Itt már nagy az eltérés. A kalibrálás menüpontból nem menti el a beállított értéket, illetve ha a kalibráló menüből kapott értéket írom át az arduinoba, majd újra programozom, akkor szintén nem kapok olyan értéket, ami használható lenne.

23 órája, DarthVödör írta:

Jó ötlet a 100/2*100 párhuzamos osztó. Ha 1% ellenállásokra kicserélnéd, a pontossága is javulna.

Már ki van cserélve, egészen jól mér. Cserébe ami fent volt program ezelőtt, amibe mérte a 100as átlagfogyasztást is, azt nem tudom hova mentettem, szóval kezdhetem előlről a program átírását, hogy a fogyasztás átlag is benne legyen 

On 2018. 12. 12. at 7:44, georgee írta:

Meglett a megoldás. Excelben az akkufeszültség matekolós részt megnéztem. Viszont ha a 100/47 értékekkel használom a feszosztót, akkor a mért érték fél volttal feljebb lesz, tehát 12v esetében 12,51v lesz a kiírt érték. Viszont ha az osztót. 94k/47k vagy 100k/50k-n használom, akkor az érték már végig pontos. Vagy szoftveres kompenzációval lehet a fél voltot "eltüntetni"(Bízom benne, hogy nem fog 15V fölé szaladni a generátor :D). A 100/50-es osztó a legjárhatóbb. Amint kész lesz és járható ez az út, jelzem.

Érdekesség: Reggelente a nagy hidegbe "nem indul" a computer. A TID a dátumot kijelzi, majd kb 8-10 perc után magához tér. A mérések megvannak, tehát az ARDUINO dolgozik a háttérben és ha magához tér a TID akkor pl az eltelt időnél a már indítás óta eltelt időt mutatja, csak épp a TID és az ardu között nincs kommunikáció. Valaki tapasztalt már hasonlót?

Jó híreim vannak. Kicsit piszkálgattam a programban. A 100/47k arányú feszültségosztót alakítottam egy kicsit 100/50-re így 15V bemenő esetén a kijelzőn az érték is 15V. Pontosabban mér mint a 300/100k arányban. Így már csak 0.1V eltérés volt amit a programban korrigáltam, így az akku feszültségét írja ki 0.5v pontossággal. 

Átalakítás annyi, hogy a panelon a feszültség osztón ellenállást cserélünk 3db 100k kell az r2 az párhuzamosan lett felhasználva. Illetve a programban az elején R1 R2 értékét R1=300000 ről 100000-re az R2t meg 50000re kell átírni a többi marad.

On 2018. 12. 07. at 8:29, georgee írta:

Ez esetben ha jól értelmezem és a 100K/47K osztót használom, akkor elég a program elején is az R1 R2 értéket is módosítanom?

Időközben összeállt a kép. Köszönöm a kimerítő választ. Azért nem jött ki a matekolás mert az A0-ra a feszültség osztóra kapott értékkel számoltam, és nem a hozzátartozó digitális értékkel.

 

Meglett a megoldás. Excelben az akkufeszültség matekolós részt megnéztem. Viszont ha a 100/47 értékekkel használom a feszosztót, akkor a mért érték fél volttal feljebb lesz, tehát 12v esetében 12,51v lesz a kiírt érték. Viszont ha az osztót. 94k/47k vagy 100k/50k-n használom, akkor az érték már végig pontos. Vagy szoftveres kompenzációval lehet a fél voltot "eltüntetni"(Bízom benne, hogy nem fog 15V fölé szaladni a generátor :D). A 100/50-es osztó a legjárhatóbb. Amint kész lesz és járható ez az út, jelzem.

Érdekesség: Reggelente a nagy hidegbe "nem indul" a computer. A TID a dátumot kijelzi, majd kb 8-10 perc után magához tér. A mérések megvannak, tehát az ARDUINO dolgozik a háttérben és ha magához tér a TID akkor pl az eltelt időnél a már indítás óta eltelt időt mutatja, csak épp a TID és az ardu között nincs kommunikáció. Valaki tapasztalt már hasonlót?

4 órája, DarthVödör írta:

magyarul bővebben.

Erre a analóg-digitál bemenetre adott jel értéke 0....1023 lehet. 0=0 5V=1023. Tehát ha az adott maximális érték 1/4 osztás alapján (a teljes létra 20V a leágazásnál 5V mivel az autóban NEM lesz 20V, csak maximum 15V, akkor az értéke 3,75V=767,25 és mivel egy kisebb skálán fér el, a felbontása, is elnagyolt lesz. Akár 0,5V-ot is léphet, ami egy kis változáskor nem mévadó. Ugyanakkor az osztók tűrése miatt is lehet folyamatosan vándorló az érték. 

100K/47K azért lenne jobb, mert a bemenet (A0) +5V-ig mintavételezhető. Vagyis felhasználnánk a teljes 1023. Ha ez osztom 1023/15V=68.2 pontossága. A 14.4V-os mintára, 982.08 érték jön ki, ami már elég jó.

Ez esetben ha jól értelmezem és a 100K/47K osztót használom, akkor elég a program elején is az R1 R2 értéket is módosítanom?

Időközben összeállt a kép. Köszönöm a kimerítő választ. Azért nem jött ki a matekolás mert az A0-ra a feszültség osztóra kapott értékkel számoltam, és nem a hozzátartozó digitális értékkel.

8 órája, DarthVödör írta:

 Ha USB-n csatlakozol az arduinora, megnézheted Serial monitoron az aktuális értéket, amit az A0 lábra kap.

Ezt megnézném. Az arduino programmal hogy tudok csatlakozni? Megnéztem 1%-os az ellenállás tűrése. Bár a 3db 100k esetébe a tűrés is összeadódik. Lehet értelmesebb lenne tényleg 1darabbal osztani. Nem értem miért így oldotta meg.

29 perce, zotya975 írta:

Hát én egy som,a voltmérőt építtettem be a műszerfalba, már ott kevesebbet mérek pár tizeddel mint az akkunál. ( csatlakozások, biztosíték..stb)Hideg motornál mindíg pár tizeddel magasabb a töltésem mint melegnél, de ez szerintem a generátor sajátossága. 

 

Valamennyit befolyásol a műszer referencia értéke is. +- pártized volt. Tehát multiméter és mutiméter között is láttam már 0,4V differenciát. Mindenesetre ma utána nézek miért vagy hol esik le a feszültség. 

47 perce, zotya975 írta:

Semmit nem értek abból leírtál ( annyit tudok a villanyról hogy megy a drótban és egy kapcsolási rajzot többnyire ki tudok bogarászni) de feszültség eshet minden csatlakozásnál, így az akku és a mérési pont között érdemes ezeket átnézni, a testkötéseket is beleértve. Ugyanazon a pontnál mérted a multiméterrel is a feszt vagy azt közvetlenül az akkunál? 

Jajj, elnézést. Kicsit belenyúltam a programozói nyelvbe :D Akkun mértem. De sokallom azt az 1V feszültség esést. Amikor beépítettem még egyezett a multiméterrel. Még az ellenállás toleranciára vagyok kíváncsi, vagy hogy a hideg idő mennyire befolyásolja a mérést. 5%-os ellenállás tolerancia esetében szerintem már előfordulhat 1V differencia. A szoftveres kalibrálásra viszont van már ötletem

1 óra, zotya975 írta:

Egészen biztos vagy benne hogy nem a multiméter ( esetleg az is) csal? 

7812 IC-n 12V-ot mérek. Szóval a hiba kizárt a multin. Ráadásul ha 11.4V lenne az akksi, akkor már nehezen indulna az autó (ha indulna). De egyből pöccre indul. Másrészről a generátor töltőfeszre is 13.4-et mér az arduino, ami szintén karcsú. És itt még semmi terhelés nincs a kocsin, csak jár a motor. Ezért gondolom, hogy az ardu körül lesz a hiba. Maga az akku rész megvan a forráskódban, csak ha elkezdek matekolni a végére nem fog kijönni 12 Volt. 

Tehát: tudjuk hogy a bemenő fesz mondjuk a példa kedvéért kerek 12V. Ezt a feszültség osztóval leosztjuk 3V-ra (a panelon az R1 R2 tag)==> Ez megy az A0-ra. Tehát a sensor value értéke ez lesz. És innentől csúszik el a számításom is. Ha elkezdem behelyettesíteni a kapott értékeket a vin az nekem akárhogy is számolom a végeredmény az 0.058, ami nem épp 12V ami kikerülne a kijelzőre. Viszont ha a sensor value értéke 3  lenne akkor  (R2/(R1+R2)) vel kalkulálva 12V lenne. Itt vagyok elakadva. Illetve ha még ki is jön a program szerint a 12V akkor kérdés a TID-en miért kevesebb 1volttal a mért érték? (Off ezért jó spanyol vagy milyen nyelvű forrásban kutakodni /off) 

 int sensorValue = analogRead(A0);
  float voltage = sensorValue * (5.0 / 1023.0);
  vin = voltage / (R2/(R1+R2));

Tehát 

int sensorValue = 3   // itt a fesz. osztón 3 voltot mérünk 

float voltage = 3 * (5.0 / 1023.0);  // 0.0146627 ezt lesz a voltage változó új értéke ami lebegőpontos

  vin = 0.0146627 / (100000/(300000+100000)); És itt a vin értéke kerül a kijelzőre ami itt matekolással nekem 0.05865 lett ami közel sem 12V

Viszont ha a sensor value 3 lenne azt az (R2/R1+R2)) taggal felszorozva 12re jönne ki, tehát így érthető lenne a képlet. 

Mivel jelenleg 12.4V a multiméter szerint az akku az ardu szerint meg 11.5 itt megint kérdés hova tűnik 1V (vagy min esik a feszültség). Tegyük fel ha esik valamin 1 volt azt szoftveresen hogy tudom kompenzálni?  Javítsatok kérlek ha valamit elnéztem!

Üdv Srácok! 

A programban az akku menüpontban a feszültség 11.5 voltot mutat, amikor multiméterrel mérve a feszültség 12.4V nyugalmi állapotban, 4-5 óra állás után. Tehát mérési hiba van. Valakinek esetleg ötlet, szoftveresen hogy tudom kalibrálni? 

On 2018. 06. 28. at 12:10, Pesi írta:

Sajnos nem jártam sikerrel az arduinoval. Egy fél órát működött tökéletesen, aztán teljesen megbolondult. Bármit próbáltam, semmi sem segített. Így mérgemben beruháztam a Veramonra.

Panelra rátetted a zavarszűrőket? :D Mert az a kapcsolási rajzon nincs rajta. Igencsak eltudja csavarni a processzor "fejét" aztán érdekes dolgokat művel, vagyis instabil lesz.  Ha jól tudom ez a rajz Corsa-hoz van tervezve. Ott mások a vezeték színek. Nem árt átnyálazni az Astra vezetékelését is. Illetve én ráoptimalizáltam a kocsimra. Az utolsó tankolás 42.7liter volt az elfogyasztott az ardu szerint és 42.7 ment bele a kút szerint. Egyébként +-1 dl eltérés van nagy átlagban. Én imádom  

Kínai ardut vettem, nekem elsőre jó volt. Egyébként hestore  ott is lehet venni.

12 perce, Maverick087 írta:

15:28-nál láthatod. A jelölés egyébként a motorblokkon van, kézikönyv szerint a blokkon és a szivattyún lévő jelölésnek egy vonalba kell esnie. Én még nem cseréltem vezérlést, tervezem csak, így csak ennyivel tudtam segíteni....

 

 

Néztem már a videót. Igazából a workshop manual másképp mutatta, de ugyanígy van beépítve. Köszönöm a segítséget. Van róla magyar videó is, csak erre az apró részletre nem igazán tér ki. A többi meg már egyértelmű

Üdv Tagok! Most cserélem a vezérlést az astrámon. X16XEL 1998-as G ferdehátú. Egy egyszerű kérdésem van. A vízpumpának a jelölése a motorblokkon a műanyag borítás alatt van? A pumpát már betettem, úgy ahogy az előző volt, össze jelöltem kiszedés előtt, de ellenőrzés céljából szeretném tudni, hogy az új pumpa egybe esik-e a jelöléssel. (Van gyakorlatom a szerelésben mielőtt jön a kérdés). Illetve ha a burkolat alatt, akkor a burkolat leszerelése nélkül látható valamennyire? A segítő válaszokat előre is köszönöm.  https://workshop-manuals.com/vauxhall/astra-g/images/astra-g-2377.jpg

15 órája, Smith írta:

A program elején a fatorCons = 14;  érték módosításával pontosítható a fogyasztás.(mondjuk attól függ miből számolod a mérést) a korábban tárgyalt 100 / ConsMed lassan áll be,legalább 30 km-t kell egyhuzamban autókázni,ezért elvettem.. 

Nekem a consmed most 11.8on van, viszont a menüből nem volt hajlandó eltárolni, így a forrásban írtam át. Igazából nekem az a 30km kocsikázás nem lényeg, napiszinten megvan így élek ezzel az opcióval. Tankolás után is kb 0.2l Volt az általam számolt és a gép által kiírt érték.

No van egy verzió, amit a saját autómra szerkesztettem, 3 tankolással teszteltem Az egyik tankolásnál 0.5 literrel kevesebbet mért a kütyü, a másikkal 3 literrel többet, illetve egy 1 literes töbletem volt. Így eltudom mondani, hogy aránylag pontosa számolás. Beleírtam az 1/L Funkciót is. Az arduino szerint 7.3as a fogyasztás. Viszont ahogy én számoltam teli tanktól teli tankig 6.77. Tehát kb elfogadható az érték. Azért jó lenne ezeket a hibákat kiküszöbölni. De mivel egy ideje már használom, így már iránymutatásnak is megfelel nekem.

Egyelőre nézzük meg az elméletedet, mit mutat, aztán agyalhatunk tovább  A hőfokméréssel hol vagy elakadva?

  char texttemp2[11];
  if (flagTensao == 0)
  {
    calcula_intervalo();
    if (intervaloMiliSecs < 100)
      mydisplay.display_message(F("Akku      "),255);  Én magyarosítottam, más esetben battery
    if (intervaloSecs >= 3)   Ez lenne az időzítés Ebben az esetben amíg az intervalo értéke nem lesz több 3nál, addig a program ezzel fog foglalkozni, és a többi menüpontot hanyagolja. Ez lesz az ami a menüt időzíti a kijelzőn, mármint a főmenü esetében. Almenükben nincs időzítés, egyből léptet. Érdemes lenne megnézni, hogy tényleg ez késlelteti e?! Ezt az értéket mondjuk egy 10 másodperces értékre növelni, vár-e a menü. Egy megszakításos rutinra kéne cserélni a késleltetést, így a programnak lesz ideje foglalkozni a bemenetek monitorozásával is. Szerintem a vízhőfokot ha méred fölösleges a fő rutinba integrálni és onnan kiszámolva kiíratni. Mivel a többi menüpont nem számol vele, csak egy értéket mérsz elég az adott menüben figyelni. Szerintem azért nem helyes az elméleted (egyelőre csak egy felvetés), mivel a feltétel az, hogy amíg a intervaloSecs nem éri el a 3-at, addig számoljon folyamatosan, így a program futása addig itt ki is merül. Esetleg ha nagyon kísérletezni van kedved, akkor a Te elméleteddel egy nagyobb értéket kéne megadni a várakozásnak, és így eldőne mi is az ami valójában a késleltetésért felelős. Mindenesetre sok sikert, írj, hogy mire jutottál

Jó hírem van, az én elméletemmel is helytálló a fogyasztás. 7.2L-t dobott ki 100-on ami nagyjából reális. Szerintem a hőfokot meglehet mérni, mégpedig, a hőgomba elől leszedni a jelet, majd ráküldeni egy feszültség osztóra. Így az ECU kivan kerülve. De ez csak egy elmélet a részemről. Ez az időzítéses dolog az ami nagyon piszkálja a fantáziámat (gombnyomás). 

3 perce, Smith írta:

Frankó megoldások,a tablet kivitelezés nekem túl egyszerű és nagy!  nincs benne elektronikai izgalom.. Ez a fából faragott átalakítás brutál,biztos volt vele meló. 

Ennyit módosítás került a menu_consumo részbe,immáron a float-al,de még nem próbáltam ki :

  float averageT = (100 / ConsMedTotal); /////////////////////////////////////////////////// Average Total / Liter per 100Kmh       
        if ((averageT >= 0.0) && (averageT < 100.0))
        {
          if (averageT < 10.0) {
            dtostrf((((float)(averageT*10))/10.0),2,1,texttemp);
          } else {
            dtostrf(averageT,3,0,texttemp);
          }
        } else  {
          ConsMedTotal = 0.0;
          averageT = 0.0;
          dtostrf(averageT,2,1,texttemp);
        }
        sprintf(textfinal,"CA %s L/1",texttemp);
        mydisplay.display_message(textfinal,255);

Ahol az averageT értéke 0-10 között tizedes értékű 10 felett egész értékű lesz.

A kijelzés ebben az esetben "CA x.x L/1".   A korábbi véleményeitek alapján a vízhőmérséklet vagy bármi méréssel kapcsolatos kijelzés a program felépítéséből adódóan nem ajánlott?  

A vízmérés érdekel, ha lenne otthon pluszba egy Ardu pa nelom és egy TID-em egy szavam nem lenne a kísérletezés miatt. Fent az AverageT is floatba van deklarálva? Ha nem akkor írd be oda, a legegyszerűbb, hogy ha a consmedtotalra rákeresel, és az első találat a deklarálása, oda írd be az averageT -t, más esetben hibát fog a fordítás hozni. Arra figyelj, hogy kis és nagybetű egyezzen. A másik, ha a menüsort nem módosítod, akkor figyelmen kívül fogja hagyni a program a futtatását.

Tehát:

A feltétel így teljesül ha megnézed fent a CASE sorokat, mindegyiknek van egy száma, ez a menüpont, ezeket a SET gomb növeli adott értékig, aholl nullázódik, tehát az első menüpontra ugrik vissza. A következő a reset gomb, ahol szintén így működik csak almenüvel, az utolsó almenü állítja a számlálót nullára, ha új menüt teszel be, akkor a menüsor +1-el bővül, pont ezen az értéken reszelődik. Tehát ha van 6 menüpont a 7 a reset érték, itt viszont a te menüpontod a 7-ik menü. Tehát a Reset érték a 8 lesz. Viszont a rutin elejére is kell egy feltétel, ami így néz ki ha "  if (flagModoInjetor == 8) " akkor fusson a rutin, ha nem hagyja figyelmen kívül Ennek a végén kell resetelni a flagModoInjetort, hogy az első menüpontra visszalépjen.

(averageT*10))/10.0)  A szorzom 10-el hogy oszthassam 10-el sor kicsit megfogott :D

19 órája, Smith írta:

Drukkolok georgee !   Igen a menübe lépkedéskor,amíg kijelzi az elnevezést addig kimarad a számlálás! Amikor elkezdtem vele foglalkozni emiatt adaptáltam a BC-t egy Teensy 3.0 board-ra (MK20DX256,32 bit ARM,Cortex-M4,72 MHz,stb.)  de akkor világosodtam meg hogy a program felépítése miatt van akadozás. Megbékéltem vele és apró állítgatások után használom,itt helyesbítenék pár dolgot (az én verzióm agyon van már alakítva) ezért rosszul írtam pár hozzászólással korábban, az eredeti szoft. az eeprom mentésekor a {TP} ikon két zárójelét jelzi (ez nálam módosítva van) a másik hogy  a "Good Bye" feliratnál menti el az utoljára használt menüt,így ha kirántod a kulcsot motor leállítást követően a következő indításnál mindig a korábban mentett menübe tér vissza.  Esetleg a LED villogtatást kiszedve próbáltad? 

A tablet megoldás a nagy mérete miatt elviszi a megszokott design-t! Én ezért vetettem el. Nálam 7" plafonból lenyíló LCD monitor van besüllyesztve a kárpitba ez is zavaró tud lenni (hosszú utakon a gyerek mozizása miatt kellett). 

ELM327-el nekem sem ment,de amit említettem azzal a legtöbb androidos OBD app. működik.A torque tud hibakódot olvasni és törölni,ezt a részét még nem próbáltam..   

A ConsMedTotal  értékét több helyen használja a program ha elállítódik más számítás is elmászik. Ezért javasoltam  byte averageT = (100 / ConsMedTotal)  a byte változóban 8 bites 0-255 értéket tárolhatunk,így nem változik a ConsMedTotal értéke. De ez a byte sem az igazi mert csak egész számértéket tud tárolni. Ezért lehet hogy teljes fogyasztási értéket kapok ami felfelé vagy lefelé kerekített? Így jelenleg városban 12 litert számol,a napokban ezt próbálom kiszámolni a tankolások alapján!   

A led lényegében csak fölösleges sor, tehát ha az kikerül, a program nem omlik össze. Nekem fölösleges, mert hátra van beépítve, így ha lefagy sem látom. A Consmedtotalal tesztelem most a gépet, Az autonomia nem ingadozik fél percenként, lényegében ugyanúgy pontos, máshol nem érzékelek eltérést. Furcsa hogy az eddigi 15km/l lement 11km/l-re aminek nem értem az okát, mert a kalibrálásba beállítottam az értéket. így 8.5-re hozza 100km-en a fogyasztást, amit sokallok. Ezt még átgondolom, mi lehet az oka.

"De ez a byte sem az igazi mert csak egész számértéket tud tárolni" ==> Floatba kell konvertálni (lebegőpontos) Más esetben kerekít, ahogy írtad is. Ha tudsz esetleg megosztani gy forrást amibe benne van ez a byte averageT = (100 / ConsMedTotal)  sor, akkor megnézem mit lehet kezdeni vele.

"A Veramon-ban is 4MHz proci van, szerintem is el kellene bírja. A WEG jel megszakításos impulzusszámlálása jó ötlet, de kombinálni kellhet áramköri szűréssel (talán RC tag), mert kiválthat fals megszakításokat ha "pereg", mint egy kapcsoló (nem tudom milyen jel jön le róla, csak egy felvetés)." A PIC az szoftveresen kiüti a pergést, szerintem az arduino is tud hasonlót. a 20MHz-t azért írtam mert még nagyobb lenne a pontossága a kütyünek.

Most egyszerre mindenkinek írok.

tgabika76 a két gomb benyomása után nekem a pályán is kidobta a bűvös 130-as tempót. 

A számláló akadozik... Nem akadozik, hanem "elcsúszik a jel" vagy időzítés hiba, ezt fentebb tárgyaltuk, tehát a számláló megy tovább, csak éppen a kijelző nem írja ki (szinkronizálási hiba). van amikor 5 perc után nincs adat, majd 14-15percnél magához tér. Maga a távolság, a forrásban a megtett távolság az alapja mindennek, tehát hátralévő kilométerek átlagfogyasztás stb. Így már logikus a túfogyasztásom, ha a kocsi szerint 500km akkor az óra szerint 460, és ott van az a 2-3 liter különbség emiatt. A csúszás az időzítés miatt van, tehát a Set gombnyomásra 3 másodperc a késleltetés minden egyes funkciónál, ami miatt a program futása megáll erre az időre, így menetközben addig kihagyja a bejövő jeleket. Ezt belső interruptos számlálóval kilehetne küszöbölni és így független lenne a késleltetéstől az adatgyűjtés.  Illetve érdemes lenne a sebesség illetve az injektort is a bemeneten interruptként kezelni, mondjuk egy 20MHz-s órajel mellett. Ebben az esetben is a 3 másodperces késleltetés így meglenne kerülve. Ha a TID-nek a vezérlését megérteném MRQ-t hogy kell használni, talán eltudnék indulni valamerre. Az elején a LED villogtatása, ami a futást jelenti, szintén csak fölösleges időzítés, ami fölöslegesen akadályozza a programot.

Smith a kérdésedre itt van némi okosítási lehetőség, más irányból közelítve is: http://cardroid.eblog.hu/tablet-kivalasztasa-6160  nekem mezei 2 din van az autóba. Tablet. 7"-os a mérettel bemegy, DE! figyelj rá a 7" a teljes beépítési méret. Nem a  teljes méretet adják, hanem a kijelzőjét, arra még rámegy a keret stb. Az oldalon számtalan opció van. A GPS-t leszavazom, mert nagyon lent van, és elveszi a figyelmet az állandó lefelé nézegetés. Bár sima 2Din  esetében is ez a helyzet.

Másik lehetőség a TID helyére bemenne egy telefon, én samsung galaxy telót akartam odatenni, és kivezetékelni a kapcsolókat, a töltés közben nem kapcsol ki opciót bekapcsolni, így gyújtás ráadása esetén már nem is kell a billentyűzár gomb (de jó ha kivan vezetékelve egy esetleges lemerülés esetére). ELM327-el nem kommunikál az autóm, 2002 előtti így ezt a megoldást elvetettem. Pedig pont illik oda, némi módosítással viszont a tapizás nehézkes lett volna. https://www.phonearena.com/phones/Samsung-GALAXY-mini-2_id6928/photos

Fogyasztás 100/on: Módosítottam a következő sort  ConsMedTotal = DistTotal/((vazaomlTotalEEPROM + (vazaomlTotal - vazaomlTotalReset))/1000.0);  ugye ez adja a km/l átlagát és CM-jelöli a kijelőn. Namost az új sor annyiba változott, hogy   ConsMedTotal = 100/(DistTotal/((vazaomlTotalEEPROM + (vazaomlTotal - vazaomlTotalReset))/1000.0));  így már a 100on kapott átlagot adja ki, nem a kilométer/liter átlagot. Viszont az autonomia is ebből dolgozik, így még csak részlegesen teszteltem a programot, ha ezt megzavarja, akkor módosítani kell pár sort, de a kijelző már l/100km-et jelez nekem a fogyasztás menüben. A sprintf(textfinal,"CM %s kmL",texttemp); sort módosítva sprintf(textfinal," %s L/100",texttemp); a kijelző így írja ki==> 5 L/100 Pontosságról még nem tudok semmit, most nekem 8.5öt mutat a városi kocsikázás mellett, holnap indulok hosszabb útra, megnézem mit mutat. 

Kezdődnek az álmatlan éjszakák, piszkál a kisördög, hogy kezdjünk valamit a projekttel. Ha megértem a teljes logikát, lehet PIC-re átdolgozom.

1 óra, freddy_ írta:

A WEG a sebességjelből, ami a bal első kerékagy jeladóból (B25 baloldalt) és az U1-es jelkonvertelből  jön. Ez megy az ABS-be (jobb oldalon) is. Tehát érvényesnek kell lennie olyan autóra is, amelyikben nincs ABS (az ábra ABS jelöléssel jelöli). A pirossal kiemelt rész megy a TID-re (ha az előző hozzászólásomban betett diagram-al összenézed, a TID 9-es lábán a WEG-re megy).

Mégegy kis adalék (talán segít) a Veramon oldaláról:
"Measurement of distance is to summarize the number of pulses per unit of ABS sensors, located on the left front wheel and is applied on the wiring harness to the display (TID, MID, etc) Number of pulses per 1 km is usually the Astra G 15385 pulses. It is also possible to set the right tire size and number of pulses per wheel revolution. The program will convert the wheel circumference and the measurement is then really accurate. Scanning input is done via the CPU interrupt the third priority."

Nyertél  ez a gondolatmenet onnan jött, hogy ismerősömnek pl a TID-en ha benyomom a két gombot egyszerre nem írja ki a sebességet, viszont ABS sincs az autójában. De gondolom attól a tid kábelban benne van a sebesség jeladónak a vezetéke. 

Más: Sikerült megértenem a megírt szoftvernek a logikáját, átlátom a menü kezelését is, mikor hogyan lép, viszont a programozási nyelv hiányos ismerete miatt nem tudok előre lépni. Flowcode programba meg a forrást sajnos nem tudom beletenni, így részemről elég nehéz a fejlesztés. Sikerült a debug menüből áttenni a tank százalékos kapacitását a fogyasztás menübe, viszont hol behozza hol nem, de már ezzel is előre léptem. Ha esetleg van újabb verzió külföldi oldalon a fordítását megoldom, ha van rá igény.

Kezdem csipegetni, csak még vannak gondok, most a távolság miatt gondolkozok, 500km-en már 40km az eltérés. A google fordító aránylag érthetően fordítja a // utáni szöveget.

DistT = (DistCount/16) * fatorDist;  Jó lenne tudni magát a sebességet honnan szedi a TID. Elvileg ABS de csak elvileg, (most nézzük el, hogy az óracsoport onnan szedi a jelet) Viszont ami nem ABS-es autó? A 16 szerintem az ABS fogak száma lenne, de az astrában 32 fog van az ABS-en tehát a distcount minden fogra lép egyet majd ha osztható a 32vel akkor tett 1 kört, amit szorzunk az abroncs futófelületével. Átírom és tesztelem, Vasárnap este írom, hogy érdemes e frissíteni. Másik, valamelyik forráskódban a CapacidadeTanque  sorba 40 volt írva G astra esetében 52