Fedélzeti computer, automenedzsment - épített megoldások, extrák

[Smith]

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!   

[nyolc8]

Ha jól láttam neten, létezik megoldás a számlálás megakadás problémára, igaz nagyban át kéne alakítani a programot. "Arduino Protothreading" a dolog neve, lényegében többszálon tud futni a program, tehát a számláló "thread" (program szál) futhat totál külön és függetlenül a többi "thread"-től, tehát a számlálás közben bármi más futhat/történhet, nem akasztja meg és a számlálót. Dolgoztam már több szálon futó programmal, igaz az C++ volt azthiszem, ha hasonlót lehet Arduino-n akkor az lenne a legszebb megoldás.

[freddy_]

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). Hamarsan meg fogom tudni, mert nekem is dolgoznom kell vele a tempomat miatt, akkor elmondom mire jutottam. Ha megcsinálom magamnak a programot, akkor megosztom veletek, de nem ígérek semmit egyelőre (szerintem veramon MID-et veszek). 38 EUR-ért a Veramon-tól meg lehet venni készen is (TID-hez valót), ha nem akartok szenvedni vele.

[tgabika76]

22 órája, Smith írta:

Én ha most kezdeném (ez is egy lehetőség) : közép box csere a nagy kijelzősre,érintős LCD kijelző felülre 4" vagy 5" (mi a pontos méret?)  ma már minden méretben kapaható,Raspberry Pi 3,android rendszer telepítése,usb-s bluetooth hozzá,Konnwei OBD ez BT-n küldi az adatokat (ezt használom) androidra Torque Pro!!  Ezzel minden adat kint van akár műszeresen a képernyőn ami teljesen testre szabható még elvileg a hiba kódok is listázhatóak. A lehetőségek határtalanok..  

5" a pontos méret ami bemegy a nagy kijelzős középboxba, de miért kínlódnál érintős LCD-vel és Raspberry Pi-vel, amikor sokkal egyszerűbb egy ekkora méretű androidos tabletet venni, és akkor akár még neted is lehet a kocsiban, ha raksz bele egy SIM kártyát... ;) Íme egy régebbi cikk hasonló módosításról, igaz ez egy Combo C-be készült, de az elv ugyanúgy használható G Astrára is: Combo C középkonzol modding. (a cikkben írnak a lehetőségekről is, amik úgyszólván végtelenek, a megfelelő app-al nem csak tolatókamera, de akár GPS nyomkövetés is megoldható.

Olyan is van aki sokkal inkább manufakturális módszerekkel állt neki a projektnek, és kihagyta a gyári nagy kijelzős középkonzolt: Astra G cabrio középkonzol modding

[georgee]

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.

[freddy_]

13 órája, georgee írta:

A PIC az szoftveresen kiüti a pergést, szerintem az arduino is tud hasonlót.

Mire gondolsz pontosan? Én nem tudok ilyenről. Nyomógomb pergést lehet szűrni áramkörből RC taggal vagy szoftverből többszöri mintavételezéssel (mondjuk 10 egyforma kapcsolóállás biztosnak vehető). Egy részletes cikk a pergésmentesítésről. Autónál arra is oda kell figyelni, hogy a hosszú vezetékek induktivitásként viselkednek és simán jelentkezhetnek negatív tranziensek is, kinyírhatja az érzékeny, védetlen áramköröket. (Cikkek a témában: 1, 2.)

Jelen esetben nem biztos, hogy kell RC tag (ha éles a fel- és lefutás). Frekvencia függvényében lehet rajta simítani (jelen esetben érdemes-e, nem tudom), de az alapjelet nem szabad eltorzítani.(Javítva: a WEG jelnél nincs pergés.) Ha 15385 impulzus egy kilométer, 180km/h-nál 769 impulzus/másodperc.

Azért, hogy ne maradjon ki a sebességjeladóról jel, mindenképp megszakítást kell használni. Ezt nem lehet megkerülni. A nyomógomboknál mindenképpen használnék RC tagot, de nem biztos, hogy megszakítást is használnék. Illetve csak akkor, ha az adott procin van többszintű megszakítás-kezelés, ahol a sebességjel a prioritásos lehet (nem maszkolható megszakítás) és a többi megszakítás (nyomógombokhoz) alárendelt. A nyomógombokat egyébként is elég másodpercenként 20-50-szer mintavételezni (80-200 ezer óraciklus 4MHz-es processzor esetén, bele kell férjen).

13 órája, georgee írta:

a 20MHz-t azért írtam mert még nagyobb lenne a pontossága a kütyünek.

A szoftver hibás elvi felépítése ellen én nem processzorerővel harcolnék. Bár tény, hogy a 32MHz-es procikat is meg lehet már kapni 1000 HUF alatt, egyáltalán nem biztos, hogy az alapproblémát megoldaná.

[Astra G CC]

Sziasztok!

Szerintem sokat lendítene a dolgon,ha sikerülne pontosan meghatározni,hogy mik az elérendő célok... (gk.-tipusok, mérendő adatok, számolandó mennyiségek).

Némi konkrét tipus ismeret sem lenne hátrány. Nem kellene felesleges dolgokon agyalni (ld.: pergésmentesítés).

Ahogy elnézem elég zavaros még a kép (lagalábbis számomra!).

 

Üdv: Zoli

ui.: Astra G Twinport 1.4 16V

 

[Smith]

17 órája, tgabika76 írta:

5" a pontos méret ami bemegy a nagy kijelzős középboxba, de miért kínlódnál érintős LCD-vel és Raspberry Pi-vel, amikor sokkal egyszerűbb egy ekkora méretű androidos tabletet venni

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?  

Módosítva Március2, 2018 : Smith

[georgee]

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

[Smith]

Sajna nekem sincs pluszba TID így nehézkes a kisérletezés,hideg van kint játszani,viszont Arduino van bőven egyéb projektekben kb. 10 félében használom. Igen az elején is float-ban van,a többit (menük működése,stb.)mind kitapasztaltam az idők során  a speed menü és az options közé bekerült a vízhőmérséklet,ugyanúgy működik mint a többi menüpont (nem csúsznak szét a karakterek). A korábbiak miatt a érdemes a menübe lépéskor értéket kiolvasni az adott bemenetről. Időközben megmértük a műszercsoport vízhőmérséklet vezetékét amin 1.2V - 5V közötti impulzusok vannak ami nekünk analóg bemenetre nem jó.  A rajzok szerint a motortérben a hőgomba (kék/piros vezetéke) közvetlenül az ECU-ba csatlakozik,a műszercsoporthoz nem ez megy. 

[DarthVödör]

On 2018. 03. 02. at 13:43, Smith írta:

Sajna nekem sincs pluszba TID így nehézkes a kisérletezés,hideg van kint játszani,viszont Arduino van bőven egyéb projektekben kb. 10 félében használom. Igen az elején is float-ban van,a többit (menük működése,stb.)mind kitapasztaltam az idők során  a speed menü és az options közé bekerült a vízhőmérséklet,ugyanúgy működik mint a többi menüpont (nem csúsznak szét a karakterek). A korábbiak miatt a érdemes a menübe lépéskor értéket kiolvasni az adott bemenetről. Időközben megmértük a műszercsoport vízhőmérséklet vezetékét amin 1.2V - 5V közötti impulzusok vannak ami nekünk analóg bemenetre nem jó.  A rajzok szerint a motortérben a hőgomba (kék/piros vezetéke) közvetlenül az ECU-ba csatlakozik,a műszercsoporthoz nem ez megy. 

Vegyétek figyelembe, hogy minden szenzor, jeladó +12V-os rendszeren van! Tehát a kimenete 0...12V! Vízhőmérséklet jeladó egy NTC (vagy PTC) ami hőmérséklet hatására az ellenállását változtatja. Temészetesen a test és a +12V közé van építva. WEG impulzusok is 0...12Vpp csak a számuk nő a sebesség hatására. (ha egy kerék fordulat x jel, akkor 100km/h sebességnél 1s alatt fordul 5x, vagyis y jel/s) Pontosabban: 100km/h sebességnél a WEG frekvencia 417Hz. Pergésmentesítés teljesen felesleges, ez egy (Hall) javítva: induktív jeladó ami nem pereg...

Módosítva Március7, 2018 : DarthVödör

[Astra G CC]

1 órával ezelőtt, DarthVödör írta:

 WEG impulzusok is 0...12Vpp csak a számuk nő a sebesség hatására. (ha egy kerék fordulat 4 jel, akkor 100km/h sebességnél 1s alatt fordul 5x, vagyis 20 jel/s) Pontosabban: 100km/h sebességnél a WEG frekvencia 417Hz. Pergésmentesítés teljesen felesleges, ez egy Hall jeladó ami nem pereg...

Több dolgot nem értek,segíts ki légy szíves!

1, milyen Hall celláról beszélsz? Nem az ABS jeléből lesz a WEG jel ?

2, ha a Hall cellán 20 Hz-es,abból hogy jön ki a 417 Hz-es WEG. (ez a freki nem kerékátmérő függő?)

[Smith]

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

Vegyétek figyelembe, hogy minden szenzor, jeladó +12V-os rendszeren van! Tehát a kimenete 0...12V! Vízhőmérséklet jeladó egy NTC (vagy PTC) ami hőmérséklet hatására az ellenállását változtatja. 

Igen,tisztában vagyunk vele! A megfelelő bemeneti illesztés megoldott,a vízhőmérséklet jeladó NTC ezt is tudjuk! A műszercsoportnál nem ez mérhető..

[freddy_]

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

Vegyétek figyelembe, hogy minden szenzor, jeladó +12V-os rendszeren van! Tehát a kimenete 0...12V! Vízhőmérséklet jeladó egy NTC (vagy PTC) ami hőmérséklet hatására az ellenállását változtatja. Temészetesen a test és a +12V közé van építva. WEG impulzusok is 0...12Vpp csak a számuk nő a sebesség hatására. (ha egy kerék fordulat 4 jel, akkor 100km/h sebességnél 1s alatt fordul 5x, vagyis 20 jel/s) Pontosabban: 100km/h sebességnél a WEG frekvencia 417Hz. Pergésmentesítés teljesen felesleges, ez egy Hall jeladó ami nem pereg...

Sejtettem, hogy a szenzor jele nem pereg. A nyomógombok viszont igen, és fent volt szó erről is. Az ingyenesen elérhető szoftver nem tökéletes, ez a fő probléma jelenleg. Kimarad a WEG jel érzékelése ha a nyomógombokat használják. A frekvencia számlálás és a nyomógombkezelés körül problémák vannak. Újra kellene írni, legalábbis részeit biztosan. (Írtam javaslatokat.)

A sajátomhoz galvanikus leválasztást (optocsatoló vagy izolátor) tervezek a WEG-hez, illetve mindenhez, ami a 12V-os rendszerről jön. Bár össze lehet rakni diódákból és ellenállásokból is, de egy kicsit jobban bebiztosítanám attól, ahogyan a projekt kapcsolási rajzán szerepel. (Ehhez javasoltam irodalmat.)

[DarthVödör]

On 2018. 03. 02. at 17:26, Astra G CC írta:

Több dolgot nem értek,segíts ki légy szíves!

1, milyen Hall celláról beszélsz? Nem az ABS jeléből lesz a WEG jel ?

2, ha a Hall cellán 20 Hz-es,abból hogy jön ki a 417 Hz-es WEG. (ez a freki nem kerékátmérő függő?)

1: Van ABS-sel szerelt és nem ABS-es jármű. Az ABS-nél mind a 4 keréknél mérik a fordulatszámot. Ha nagy az eltérés az ABS korrigálja a fékerőt. ABS-ből hozzák ki a WEG jelet. A nem ABS-sel szerelt járműveknél a bal első kereket mérik. Itt egy "relé" is van a multitimerben. Gyakorlatilag egy erősítő. A Hall jelét még nem lehetne mérni.

2: zárójelben csak egy példa volt, a könnyebb megértésért. Utána írtam hogy Pontosabban:417Hz/100km/h. Igen, átmérő függő ez a frekvencia. Nagyobb átmérőjű keréknél 417Hz jóval 100km/h felett éri el! Tehát csal, az óra, lefele!

On 2018. 03. 02. at 19:25, Smith írta:

Igen,tisztában vagyunk vele! A megfelelő bemeneti illesztés megoldott,a vízhőmérséklet jeladó NTC ezt is tudjuk! A műszercsoportnál nem ez mérhető..

Pontosabban a tachóban az ECU jelét mutatja. NTC jele sokkal kisebb. Az ECU csinál mérhető jelet a tacho/cooling számára.

Módosítva Március4, 2018 : DarthVödör

[Astra G CC]

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

1: Van ABS-sel szerelt és nem ABS-es jármű. Az ABS-nél mind a 4 keréknél mérik a fordulatszámot. Ha nagy az eltérés az ABS korrigálja a fékerőt. ABS-ből hozzák ki a WEG jelet. A nem ABS-sel szerelt járműveknél a bal első kereket mérik. Itt egy "relé" is van a multitimerben. Gyakorlatilag egy erősítő. A Hall jelét még nem lehetne mérni.

2: zárójelben csak egy példa volt, a könnyebb megértésért. Utána írtam hogy Pontosabban:417Hz/100km/h. Igen, átmérő függő ez a frekvencia. Nagyobb átmérőjű keréknél 417Hz jóval 100km/h felett éri el! Tehát csal, az óra, lefele!

Pontosabban a tachóban az ECU jelét mutatja. NTC jele sokkal kisebb. Az ECU csinál mérhető jelet a tacho/cooling számára.

Köszi!

A G Twinport 1.4 16V-nek az ABS jeladója -ha jól tudom- induktív és 32 imp./ford. jelet ad. A WEG jel ez a jel vagy már egy elektronikusan feldolgozott jel (amplitúdó,jelalak,kitöltési tényező) ? A 417Hz (gondolom!) erre vonatkozik,mert a 4db HAll nem ad ennyit számításaim szerint.

Zoli

 

[freddy_]

1 órával ezelőtt, Astra G CC írta:

Köszi!

A G Twinport 1.4 16V-nek az ABS jeladója -ha jól tudom- induktív és 32 imp./ford. jelet ad. A WEG jel ez a jel vagy már egy elektronikusan feldolgozott jel (amplitúdó,jelalak,kitöltési tényező) ? A 417Hz (gondolom!) erre vonatkozik,mert a 4db HAll nem ad ennyit számításaim szerint.

Zoli

 

Ha egy oldanyit visszalapozol, megtalálod a kapcsolási rajzot. (Ne a beidézetettet nézd, mert hibásan írtam először és javítottam a hozzászólást.) Én is kíváncsi vagyok a jelalakra, de végeredményben a felfutó vagy lefutó éleket kell számolni, ilyen szempontból mindegy.

[Smith]

Tök jó hogy erről témáztok  tetszik,lehet belőle tanulni! Ezek után felmerült bennem a kérdés hogy mihez kalibráljam az arduino-s BC-t, egy egyenes útszakaszhoz  amit kilométer tábla jelzéssel elláttak vagy a napi km számlálóhoz? (amit a téli/nyári gumi minimális eltérésénél megint kalibrálni kellene..) 

[freddy_]

3 órája, Smith írta:

Tök jó hogy erről témáztok  tetszik,lehet belőle tanulni! Ezek után felmerült bennem a kérdés hogy mihez kalibráljam az arduino-s BC-t, egy egyenes útszakaszhoz  amit kilométer tábla jelzéssel elláttak vagy a napi km számlálóhoz? (amit a téli/nyári gumi minimális eltérésénél megint kalibrálni kellene..) 

Szerintem GPS-hez egyenes útszakaszon. Felmerült bennem, hogy szerzek egy GPS modult és önkalibráló lesz. Esetleg GPS nyomvonalat tud menteni SD kártyára, stb.

[Astra G CC]

12 órája, freddy_ írta:

Ha egy oldanyit visszalapozol, megtalálod a kapcsolási rajzot. (Ne a beidézetettet nézd, mert hibásan írtam először és javítottam a hozzászólást.) Én is kíváncsi vagyok a jelalakra, de végeredményben a felfutó vagy lefutó éleket kell számolni, ilyen szempontból mindegy.

Szia!

Melyik kapcsolási rajzot nézzem?

A feltett kérdésemre :

" ha jól tudom- induktív és 32 imp./ford. jelet ad. A WEG jel ez a jel vagy már egy elektronikusan feldolgozott jel (amplitúdó,jelalak,kitöltési tényező) ? A 417Hz (gondolom!) erre vonatkozik,mert a 4db HAll nem ad ennyit számításaim szerint. "

egyik sem ad választ...

[georgee]

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

[Smith]

1 óra, georgee írta:

 Ez az időzítéses dolog az ami nagyon piszkálja a fantáziámat (gombnyomás). 

A hőgomba mérése a napokban tervben van. Elviekben valamit csináltam . A gond ugye a menü nevének kiírásakor az idő várakozása.A várakozási rész a calcula_intervalo(); ,oda be hívtam a "coisas_a_fazer_sempre" részt amiben a bemeneteket figyeli és számolja így a várakozás alatt is fut az a rész,elviekben a gyakorlatban majd kiderül A fordítás lefutott a program tesztre készen autóban. Ha ez ennyire egyszerű lenne a program készítője miért nem tette bele? 

[georgee]

  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

Módosítva Március6, 2018 : georgee
Elírás

[Smith]

1 órával ezelőtt, georgee írta:

  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.

Így van,ezt feltételeztem én is ezért módosítottam amit előtte írtam.még csak rövid távon tudtam próbálni de végig nyomkodtam a menübe lépkedést semmi elcsúszás nem volt a napi km számlálásnál a gyári méréshez képest. A vízhőfok menüje pont így van megcsinálva,csak a menübe lépés után olvassa a bemenetet. Megmértük a hőmérőt,a szerviz programban leírtak alapján : 0°/ 2.92V - 20°/2.1V - 30°/1.45V  - 40°/1.11V majd 50° felugrik 3.42V-ra - 60°/3.11V - 70°/2.70V - 80°/2.34V stb.  mérés közben a Torque .app írta a hőmérsékletet. Ötlet?

[georgee]

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