AFR, EGT, RPM, BOOST, IAT ATD data logging

[Libor12]

35 je hodně zajímavé. Jen 4x egt s loggem je cca 14000 bez čidel. Knock monitor s zobrazením 8000,hladinoměr,kvalita oleje od gilsensor 37000 Regulace ewp 6000 a o ostatním nemluvím. Když to budu chtít poskládat z jednotlivých komponent třeba od plx tak jsi zhruba na 60+ nemluvě o dopravě a poplatky tomuto státu. . Jeden jejich imfd je schopen zobrazit pouze 4hodnoty. Takže potřebuješ nejméně 3. A už to je 600usd. Cena modulů a zjistím že tvoje řešení je za třetinu. A myslím že když někdo dá do motoru čtvrt mega tak se ho bude snažit hlídat. Dle mého názoru by to bylo za tu cenu bez problémů prodejné a nejen u nas. Edit: teplota,kvalita,hladina oleje by se nechala asi jedním čidlem bosch sgm 110.

[RedX]

Libore to už je šílenost chápu že to vychází z tvejch požadavků, ale je to od původní myšlenky na malou, jednoduchou a levnou (všechno relativně) krabičku na míle vzdálený.

semysak: jak se člověk dostane k takovejm věcem co děláš? elektrotechnická VŠ?

Mně by se líbilo kdyby ta krabička uměla posílat data do ntb, tak aby je v přišlušným sw bylo možný sledovat online plus by byl prováděn jejich zápis do tabulky kterou by si pak člověk mohl celou detailně projít. Pro každý jednotlivý okamžik by byla známá hodnota ze všech čidel, interval by si mohl nastavit uživatel. Udržet HW krabičky co nejjednodušší, spíš aby sloužila jako mezičlánek mezi senzory a samotnym PC. Všechny ty alarm/warning funkce by obstarával ten sw. I když něco takovýho asi už existuje, alespoň Brian ve F&F to měl v eclipse Bez PC by to pak fungovalo jen jako naprosto základní indikátor, display ukazující vždy jen jednu veličinu plus nějaká ta dioda a pípák.

[LJay]

Osobně si myslím, že mít to všechno v jedný krabici je strašně neefektivní. Celý ten projekt by kvuli tomu byl nehorázně komplikovaný a nákladný na vývoj a ve finále to nebude ani levný, ani univerzální, protože lidi by pak museli zaplatit třeba i za funkce který nikdy nevyužijou.

Kdysi sem svůj názor na to Liborovi říkal a podle mně je nejrozumnější systém složený z modulů, který si budou mezi sebou předávat data po seriové lince (nejlíp CAN BUS).

Dělení modulů by mělo vypadat asi takhle:

- moduly pro sběr dat z čidel
- modul pro zobrazení nasbíraných dat
- modul pro záznam nasbíraných dat
- výkonové spínací moduly

Díky týhle koncepci si to celý zachová velkou univerzálnost a hlavně to půjde vyvíjet po etapách.
V uplným základu by pak člověku stačily jen příslušný moduly pro sběr dat a notebook, který by data z modulů zobrazoval v nějaký rozumný formě.

Časem bych se do toho rád pustil, ale nejdřív musím dodělat všechno co mám rozdělaný.

[semysak]

ta cena je priblizne a urcite bez cidel, s cidlama to je vice

ono to neni az tak slozite z hlediska hardware, egt=termoclanek= analogovy vstup s velkym zesilenim, ostatni je v podstate dc analogovy vstup, knock sensor = ac vstup s velkym zesilenim, klika vacka a dalsi je digitalni vstup, spis de o to jestli se mas pripojit na stavajici cidla tak zalezi co vyrobce toho ktereho auta vymyslel...

pwm vystup nebo rele zadne velke invesitce

vestsina funkci je stejne v software.....

pokud jde o modularni reseni tak tech je na svete minimalne jedno, to od plx.

RedX: jo to sem studoval

[LJay]

semysak: jj HW stránka věci není až tak přehnaná, i když třeba na ten knock by si nejspíš potřeboval samostatný mcu, který je schopný vytvořit digitální pásmovou propust.

Dost horší by byla SW část toho zařízení, protože pokud by to mělo mít všechny parametry co Libor vyjmenovával uživatelsky nastavitelný přímo na tom zařízení, tak už to bude chtít naprogramovat poměrně komplexní menu.

Další věc je kolik strojovýho času by ti vzala obsluha všech AD, DA převodníků, čítačů a PWM výstupů, aby tam zbyl čas taky na zobrazování a indikaci s nějakou rozumnou obnovovací frekvencí.
Navíc za tyhle peníze už lidi budou nejspíš očekávat i nějakou rozumnou grafickou a designovou stránku celý věci a to jsou taky nemalý náklady.

Řešení od PLX znám a příjde m rozumný. Už třeba jen kvuli tomu, že nemusíš tahat velkej svazek drátů od snímačů přímo k hlavní jednotce, ale přitáhneš to k lokálně umístěnýmu modulu a dál už táhneš jen data po jednom páru vodičů. Právě kvuli tomu vzniknul i CAN BUS, aby se snížilo množství kabeláže v autech.

Vzhledem k trendu jaký je v poslední době. By bylo asi nejefektivnější postavit "jen" převodník signálů z čidel na data a připojit to k nějakýmu embedded PC, na kterým by běžel systém a v něm aplikačka pro vyhodnocování/zobrazování naměřených údajů. Případně by v tom převodníku mohly být i výkonový/spínací členy, který by ta aplikačka zpětně ovládala. Stavět to celý kompletně od základu se podle mýho nevyplatí, když vezmeš v potaz ceny běžně dostupných embedded zařízení.

[Libor12]

takže největší problém je sw? Když k plx připojiš víc modulů vzorkovaci frekvence se zpomalí. Proto pro AFR a EGT doporučuji samostatné zobrazovace. Co k zobrazení použít tablet? Ty nejlevnější už jdou kolem 2000 za 5" čidla polohy kliky a vačky jsou z 98% identické,jestli je to japonec nebo francouz. Sloučení do OBD2 má svoje výhody,to samé platí pro knock senzory,teploty a další. Zrovna tak "K" termočlánky pokud je v daném rozsahu -50-1100 je úplně jedno kdo ho vyrábí. Elektrické parametry jsou totožné.

[Beaver]

Levný tablety jedou na Androidu a aplikace pro Android jsou z velké části psaný v Javě, což s výkonem je teda dost problém. Je sice možný je psát i rovnou v Céčku, ale jen jejich části, kde potřebuješ vyšší výkon, ale není to jen tak - ono zase pro změnu potom žere výkon když aplikace za běhu přepíná mezi kódem v Javě a kódem kompilovaným z Céčka. Pokud je mi námo, bylo to navíc možný takhle dělat jen pro ARM procesory, což těžko říct jestli ten levnej tablet mít bude. Osobně bych doporučoval jít spíš cestou miniPC s Linuxem, kde je možný kód aplikace potom kompilovat přímo pro danou platformu a rychlostně by to pak mohlo zvládat ty periferie bez problémů. Předem upozorňuju, že to je jenom můj názor a kodéra už nedělám dlouhý roky (a i před tím jsem SW dělal velmi málo), takže bohužel nejsem v pozici, kdy bych se mohl podílet na vývoji

[semysak]

no ve vetsine tehle zarizeni jsou pouzity procesory ARM,

spis tam de o to ze to softovani je hodne slozite, o vetsinu hardware se muze dobre postarat DMA a nejake cyklicke preruseni precijen dnes ty levne mikroprocesory sou kolem 100MIPS, v tomdle pripade vychazi to vzorkovani vstupu pomeren na nizky hodnoty, zase zalezi jak a co by sem elo pocitat

[LJay]

Největší problém je podle mně čas, který by si realizace takovýho projektu vyžádala. Pokud by to mělo splňovat všechny tyhle požadavky:

já bych tam viděl EGT 4x,teplotu vzduchu,voda 2x,olej,2x,knock 2x s možnosti nastavení a zobrazení frekvence, vacuum 1x,vac/boost1x,2x tlak oleje,tlak paliva 1x a lambda sonda vstup 0-5 a vystup pro ecu,snímání polohy kliky,vačky,tps,hlídání hladiny a kvality oleje. K těm teplotám vody nějaký vystup 1x1A na rele ventilátoru a pwm vystup pro elektrickou vodní pumpu,pwm pro ovládání otáček čerpadla v závislosti na teplotě,možnost u tlaku a teplot nastavení limitních hodnot s výstrahou překročení pěkně všechno na jednom displayi.

tak se to složitostí vyrovná malý řídicí jednotce a realizace takovýho projektu si vyžádá měsíce práce (návrh zapojení, DPS, design, napsání a odladění FW, tvorba uživatelského interfacu, zátěžové testy přímo v autě, ...), protože pokud při tom budeš muset chodit do práce starat se o rodinu, atd, tak tomu budeš moc každý den věnovat jen pár hodin a díky tomu se celý projekt potáhne nehorázně dlouho.

Právě i proto mi pro případnou realizaci příjde lepší, řešit to modulově, protože tím se celý projekt rozčlení do víc segmentů, který bude snažší realizovat a pokud by se to případně nedotáhlo do konce, tak ti zůstane v ruce alespoň něco použitelnýho.

[LJay]

Co se týká zpomalení vzorkovací frekvence při připojení víc modulů u PLX, tak tam to bude pravděpodobně spíš záležitostí datový prostupnosti komunikační linky a způsobem obsluhy mezi procesorový komunikace.

Tabletům bych se asi vyhnul právě kvuli Javě a taky kvuli tomu, že ty levný čínský tablety nebývají zrovna nejkvalitnější zařízení.

Osobně bych upřednostňoval zobrazovací aplikaci psanou pro platformu x86 (zatím je nejrozšířenější), takže by si jí člověk mohl spustit na svým HW a jenom se připojit na datovou linku mezi moduly. V dalším kroku by pak bylo možné dodávat i HW na kterým by ta aplikace běžela.

[Beaver]

Idealni by bylo psat to fakt primo v C/C++ a pro x86 s tim, ze zkompilovat to pod Wokna da te aplikaci asi nejvetsi univerzalnost. Komunikovat by to melo pres USB, to je k dispozici v drtive vetsine notebooku i PC.

[semysak]

no stejne je skoro jedno pokud mas modul, ktery ma 20 vstupu nebo jeden, vzdy musis nejdriv pres nejaky processor poskladat ten datovy paket, navic cim je tech modulu min, tak treba pri pouziti zbernice CAN si moc nepomuzes, protoze podle can ma paket 0-8 bajtu, coz znamena ze pri rozliseni 12 bitu muzes poslat najednou max 5 nejakych hodnot, potom musis davat vice paketu a pokud tam budou dalsi moduly tak se urcite stane ze dojde k arbitrazi a ty data enmusi prijit v casove posloupnosti zasebou jak to bylo vyslane. navic uz vidim jak treba super giga tablet, kde si nekdo zapne synchronizaci pres wifi najednou bude mit real time odezvu nekolik sekund, kdy se tam neco podela a nebo se ti ztrati data..., ten tablet je asi jedine pouzitelnej na nastavovani a potom na nejake pekne zobrazeni

[Beaver]

No i proto bych doporucil to USB a normalni notebook s rozumnym CPU, kde nebude problem stihat to zpracovat. Ja osobne bych to pro tablety primarne urcite nedelal. CAN sbernici neznam, ale pokud nebude pozadovano, aby se to napojilo na existujici vedeni, tak je lepsi jit cestou vlastni sbernice s dostatecnou rychlosti (potazmo frekvenci). I stara specifikace USB 1.1 ma urcite dostatecnou propustnost na to, aby nebyl problem sbirat data z mnoha modulu, ten datovy paket s udajem o teplote nebo dejme tomu otackach je velmi maly. I kdyby se odeslal pri kazde otacce pri 8000 rpm, tak to mam nejakych 133 paketu za sekundu (coz si myslim ze je dost zbytecne) a USB 1.1 propusti nejakych 12 Mbit. 8mi bajtovy paket nasobeny 133 dava lehce pres kilobajt a skrz ten port bych mel byt schopnej tlacit pres jeden mega za sekundu, coz je rezerva pomerne znacna.

[Libor12]

Abychom v tom udělali pořádek. představoval bych si něco takového... http://www.racepak.com" onclick="window.open(this.href);return false; ceny nikterak netají. mě nevadí ta cena. Vím že to stalo čas námahu atd. Ale proč sakra mám zvyšovat životní úroveň nějakého američana,potažmo jejich ekonomiky!? Proč ty prachy nemůžu dat někomu tady?! Vždycky tu byli chytří a šikovní lidé co z ho*na upletli bič. Proč tomu tak není dál? To už jsme taková tupá konzumní společnost neschopná vydat trochu té vlastní námahy? A když už tu něco vznikne,není to ani použitelné a je to na úrovni 90let minulého století. Viz odkaz v začátku. Ten logger dává real time data vytažená přímo z ecu s sekundovým zpožděním. Viděl jsem to ve funkci a je to ubohé. V nastavení jednotky je menu časově synchronizace. P.s. Nikoho jsem se nechtěl dotknout. Ani Martina ani Ljay. Prostě asi jsem moc velký patriot.

[semysak]

podleme je problem v tom, ze v usa je lidi, ktere si takovouhle vec poridi tisice a i vice, v cechach kolik byto chtelo lidi? 2? 3? 4?

pokud de o pleteni bice z hoven, uz to asi davno o tom neni, protoze to hovno, z kteryho se plete je stejny jak v usa i unas, priblizne od poloviny 90tych let.

[Libor12]

určitě by jsi jich neprodalo u nas tisíce, ale vzhledem k tomu,že loni jsem já sám v USA nechal 18000 za plx a innovatte by to za úvahu možná stalo... Nic neřešme to. Nejde a hotovo. Budu to tam kupovat dál a jiní také.

[semysak]

tak pokud si tam nechal 18000 usd tak mi to prije docela dost, kazdopadne v mem aktualnim case a prostoru na pokracovani projektu nemam kapacitu