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.

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

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.

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?

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.

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.

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.

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

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?

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.

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

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).

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

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.

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