Tiedonkeruukortti dynoon SimpleDyno softalle

[kkuula]

Olin juuri samaa kysymystä rustaamassa
-tai taitaa siinä mittaustarkkuus kärsiä, mutta onko merkitystä?

Triggerin taajuuden pudottaminen ei muuta sähköistä kytkentää mitenkään, ainoastaan siirtää tuon SimpleDyno softan rajoituksen ylemmäksi. Tuolla viimeisimmällä versiolla missä prosessorina esp onnistuu jo mitata ainakin 2600rpm rullan nopeuteen asti mikä riittää suurimmalle osalle käyttäjiä.

Tuo triggerin signaali on erittäin erittäin hidas ja ongelma alkuperäisellä kytkennällä alkoi jo n.15Hz trggerin taajuudelta esiintymään.

 

[kkuula]

Voi olla tyhmäkin kysymys tai jo jossain vastattu, mutta millä nopeudella tuota sarjaporttia ajetaan?

Sarjaportin nopeus 115200 enkä ole siinä huomannut ongelmia tai katkoksia. Täytyy kaivella tähän sen koodinpätkä näkyville niin näkee millaista dataa se lähettää.

Osa ongelmaa on tuo SimpleDyno softa sen korjaaminen olisi yksi vaihtoehto, pitäisi vaan löytää ilmainen koodari hommaan viikoksi

 

[kymi]

Sarjaportin nopeus 115200 enkä ole siinä huomannut ongelmia tai katkoksia. Täytyy kaivella tähän sen koodinpätkä näkyville niin näkee millaista dataa se lähettää.

Osa ongelmaa on tuo SimpleDyno softa sen korjaaminen olisi yksi vaihtoehto, pitäisi vaan löytää ilmainen koodari hommaan viikoksi

Pitäis tuo 115200 kyllä riittää. Toki se nopeus ei kulje käsi kädessä sarjaportin mahdollisten katkosten kanssa, mutta tuo väylä on kuitenkin melko robusti, eli en usko siellä olevan ongelmaa.

Löysin jonkun arduino-koodin ja se stemmaa tuohon yllä olevaan viestiini rakenteen suhteen. En ole mikään arduino-spesialisti, mutta mielestäni lasketaan melko io-kalliisti tuota kierroslukutietoa ja aikaa (ja sitä ei kuitenkaan täysin hyödynnetä, ja melko turhana pidän ohjelmallista buffer overflow keinotekoista hanskaamista arduinon puolella aikakeskeytyksen funktiossa). Ohjelman runko on käytännössä yksi keskeytysrutiini, aikakeskeytysrutiini (ja sen overflow-rutiini) ja main-loopissa oletuksena 20 millisekunnin (20000 mikrosekunnin) välein viestin generointi, jossa aika-arvojen sijoitus erillisiin muuttujiin tapahtuu nointerrupts() -tilassa (eli kieltänee kaikki keskeytykset = aika ja kierrosluku ei juokse ja seuraavassa onnistuneessa tulee iso porras). Käsittääkseni jotain noita funktioita voisi muuttaa myös natiiveiksi, jolla ehkä säästää kellosyklejä muulta (esim. main loop tarkistaa if-kutsulla onko nykyinen aika vähennettynä edellinen lähetysaika enemmän kuin määritelty 20000 mikrosekuntia, tuon voisi tehdä delay-suvun funktiolla, jolloin main-loop on holdissa - etenkin kun tuo käyttää lähetyksen jälkeistä timestampia, niin sillä ei ole merkitystä).

En arduino-tyylisten vermeiden keskeytyksien hallinnasta ja priorisoinnista juurikaan tiedä, niin paha sanoa. Samoin en osaa arvioida noiden suorituskykyä suhteessa johonkin muuhun. On taas varmaan mun omia ajatuksia, mutta jotenkin haluaisin tuota kommunikaatiotasoa minimoida tuosta nykyisestä, suoraviivaistaa rpm info ja sen jälkeen ajaa sarjaportti niin täyteen kuin irtoaa. Nyt mitä noita koodeja katsoo, ohjeita ja koodien kommentteja lukee, niin menetetään suorilta jo paljon dataa tai tarkkuutta kun mitään ei käsitellä akuutein arvoin vaan pyöristetään ja linearisoidaan - kuitenkin raja-arvojen sisällä mikä taas aiheuttaa isoja poikkeamia.

Ihan pienellä en kyllä ala koodia pyörittämään vaikka aihe onkin mielenkiintoinen. Mutta toivon, että näistä mun ilmaan heittämistä random ajatuksista on apuja ees sen verran, että jotain muuta kautta löytyy paremmin koodeja ymmärtäviä propellihattuja.

 

[alfred_j_kwak]

Ja saahan noita erillisiä laskuripiirejä vaikka tuon jo tyrkytetyn I2C:n perään, niin saa sen kuorman kokonaan pois Arduinolta/ESP:ltä.

 

[kkuula]

Hyvä että tuli keskustelua aiheesta, auttaa varmasti osaltaan hommaa eteenpäin.
Ongelma ei ole uC:n nopeus, triggeriltä tulee pulsseja sanotaan äärimmäisen maksimi 100hz taajuudella, ongelma on tuon dataformaatin pituus eli koko datapaketti on saatava lähetettyä ennen kuin uusi triggerin pulssi tulee tai muuten dynosofta sekoilee. Arvioni mukaan ESP:n toinen prosessoriydin jolla lähetettävän datapaketin koonti tehdään on lepotilassa vähintäänkin 99% ajasta ja toinen ydin lähettää datapaketin aina kun vanha datapaketti on lähetetty ja uusi on saatavilla. Nyt en ulkoa muistakkaan mikä oli tuon aikaleiman tarkkuus oliko milli vai mikrosekuntia, ihan sama sinällään koska tarkkuus on rullan nopeudelle on riittävä ja piirtää homman toimiessa nätisti käppyrää. Jos Dynodoftan vastaanottama datapaketti ei ole täydellinen menee softan sarjaliikenne vikatilaan ja tälä perusteella sarjaliikenne toimii hyvin.
Tällähetkellä ei ole tiedossa saisiko tuota PC softaa ja dataformaattia korjattua.

Pohjustuksena tuosta ESP:stä, siinä on kaksi prosessoriydintä jotka voi toimia toisistaan riippumatta mutta käyttävät samaa rautaa ja muistia ja koodarin pitää itse koodissa hoitaa riippuvuudet ja päällekkäisyydet eli varmistettava ettei yritetä samaa resurssia käyttää yhtäaikaa. Prosessori kellotaajuuus on 40MHz mutta IOn päivitystaajuus oli 1-2MHz ja IO keskeytysten samaa luokka joten maksimi 100Hz ei tuota ongelmia.
Kokeilin omassa ESP32 toteutuksessa montaakin eri lähestymistapaa, kaikissa yhteistä että käytetään toinen ydin hoitaa pelkästään dadan lähetyksen. Kaikissa kokeiluissa homma kulminoitui samaan ongelmaan eli datan lähetysten väliseen aikaan mikä määrittää minimi triggeripulssien välisen ajan.
Tuolla sain homman toimimaan noin 45-50Hz triggeripulssin nopeudelle asti eli vajaa 3000rpm rullan nopeudelle mikä ollee suurimmalle osalle dynon rakentajia riittävä maksiminopeus rullalle.

Sitten onkin toinen juttu tuo moottorin pyörimisnopeus, oletuksena se käyttää samankaltaista laskentaa pulssien aikaleimoille ja omaa ehkäpä saman ongelman, tätä en ole kokeillut. Siinä pitäisi pystyä mittaamaan vähintään sanotaan 18000rpm eli luokkaa 300Hz. Tämä jäänee haaveeksi jos ja kun PC softaa ei saa korjattua.

EDIT: Voinee myös olla että Arduino ympäristössä tuossa ESP:n sarjaliikennekirjastossa on omat hidasteensa ja voisi ehkä olla hyvä käyttää ESP:n sarjaliikennettä ilman arduino ympäristön lisäämää tauhkaa.

 

[alfred_j_kwak]

Vaikuttaako dynon toimintaan jos nuo Arduinolta/ESP:ltä lähtevät datat puskuroidaan johonkin ja lähetetään siitä PC-softalle? Vaikka joku Raspberry tuohon väliin ja siihen FIFO. Siinä voi sitten tutkia tukehtuiko PC pullaan ja jos niin Heimlichin jälkeen työnnetään sama pulla uudelleen. Pysyy aikaleimat reerassa ja sarjaliikenne saa työntää torven täydeltä.

EDIT: Tai saa sen FIFO:n sinne ESP:llekin, mutta Arduino voi olla kovilla homman kanssa.

 

[Jammu]

Niin vähän ihmetyttää, että mikä on tarve lähettää kaikki data samassa paketissa. AD-muunnin on usein kun tarkkuutta vaaditaan, hiukan hidas. Periaatteessa voisi olla niinkin että olisi eri prossu hoitamassa anturit tai esim. joka neljännessä viestissä anturitietojen lähetys (tietämättä lähestystaajuutta)

Edelleen penäisin sitä että käytetään hardwarelaskuria mikrokontrollerissa siihen taajuuslaskentaan, keskeytystä voi käyttää kun laskuri pyörästhää, laskuri sidottu kontrollerin kellotaajuuteen jonka lähde toivottavasti kide joka tarkka.

Jos mikrokontrolleri laskisi taajuudet niin viiden datakentän sijaan riittäisi laskettavaksi kaksi? Lienee koodillinen toteutus liian raskas, kyllähän luulisi että nuo hommat hoitais jo 4MHz prossun kellotaajuudella..

 

[kymi]

Vaikuttaako dynon toimintaan jos nuo Arduinolta/ESP:ltä lähtevät datat puskuroidaan johonkin ja lähetetään siitä PC-softalle? Vaikka joku Raspberry tuohon väliin ja siihen FIFO. Siinä voi sitten tutkia tukehtuiko PC pullaan ja jos niin Heimlichin jälkeen työnnetään sama pulla uudelleen. Pysyy aikaleimat reerassa ja sarjaliikenne saa työntää torven täydeltä.

EDIT: Tai saa sen FIFO:n sinne ESP:llekin, mutta Arduino voi olla kovilla homman kanssa.

Niin vähän ihmetyttää, että mikä on tarve lähettää kaikki data samassa paketissa. AD-muunnin on usein kun tarkkuutta vaaditaan, hiukan hidas. Periaatteessa voisi olla niinkin että olisi eri prossu hoitamassa anturit tai esim. joka neljännessä viestissä anturitietojen lähetys (tietämättä lähestystaajuutta)

Edelleen penäisin sitä että käytetään hardwarelaskuria mikrokontrollerissa siihen taajuuslaskentaan, keskeytystä voi käyttää kun laskuri pyörästhää, laskuri sidottu kontrollerin kellotaajuuteen jonka lähde toivottavasti kide joka tarkka.

Jos mikrokontrolleri laskisi taajuudet niin viiden datakentän sijaan riittäisi laskettavaksi kaksi? Lienee koodillinen toteutus liian raskas, kyllähän luulisi että nuo hommat hoitais jo 4MHz prossun kellotaajuudella..

Täs on just teillä molemmilla paljon sitä mitä itellä. Eikä ole tarkoitus näitä toteutuksia vertailla/arvostella (ja alfredin aikaisempi keskeytyksien ulostaminen oli hyvä).

Mua edelleen haittaa isosti tuo keskeytyshässäkkä. Etenkin kun ajetaan keskeytyksiä aikaan ja oikeaan keskeytykseen. Näiden keskinäinen prioriteetti ja mahdolliset ulkopuoliset keskeytyksien kiellot?

Näihin sitten vaikuttaa sekin, että kuka ja mikä laskee ajat aikasuhteet, millä syklillä (nyt osin keskeytyksillä).

Sit tosiaan on tuo sarjaportti, mikä ainakin itselle on arduinossa/esp:ssä tuntematon rajapinta. Writeln ja flush. Jääkö nuo prossun hoidettaviksi? Esim. taas 8051 kanssa sarjaliikennepuskurista on huolehdittava koska sarjaliikenne on ajallisesti kallista (vaikka baudeja olisi).

Millä nuo (useamman coren) prossun ytimet synkkaa ja keskustelee keskenään? Mikä on järkevää tiedonvaihtoa ja mikä taas toisaalta ihan turha?

Jos SimpleDyno paketti-arkkitehtuurina voidaan unohtaa, niin mä edelleen painottaisin sitä, että lähtöpäästä (arduino/esp) ajetaan dataa sarjaporttiin mahdollisimman paljon ja tämän prosessointi tehdään sitten tietokoneella.


Keskeytyksien kautta laskeminen on muutenkin jo kallista, ja tuossa lasketaan aikaa keskeytyksien kautta, jonka lisäksi vielä sarjaportille keskeytyksiä, niin on tosiaan muutaman kymmenen rivin koodi aika keskeytyksissä aina. Pitäisi oikeasti muodostaa jotain järkevää eikä aikaleimaa ja aikaleimaeroja. En tiedä miten arduino/esp hoitaa sarjaportin keskeytykset, mutta yleensä etenkin sarjaporteilla ovat varsin kalliita.


Ja tuollaisessa staattisemmassa epä-multiprosessoinnissa pitäisi sen kuormittamattoman prossun/coren tietää mitä sillä kuormitetulla on menossa. Helposti ajaa tuossa tilanteessa toisen prossun/coren tappiin ja toisella ei ole kuormaa kun tämä kuormitettu prossu ei pysty sitä jakamaan.


(viittaukset arduino-softaan perustuu ihan netistä löytyneisiin koodeihin mitä oon yrittänyt ymmärtää)

 

[alfred_j_kwak]

Arduinossa ei ole mitään valmista virheenhallintaa sarjaportille. Jonkinlaisen karvalakkimallin voisi tehdä tsekkaamalla ennen lähetystä onko portti vapaana, mutta se vain siirtää ongelman.
Ilman mitään takuuta syntaksista tai ajatuksen toimivuudesta, niin jotain tuollaista:

// Tarkistetaan onko lähetyspuskurissa tilaa
if (Serial.availableForWrite() > AllResult.length()) {
  Serial.println(AllResult);
  Serial.flush();
} else {
  // Virheenkäsittely pitäisi olla tässä, mutta...
  Serial.println("Lähetyspuskuri täynnä"); //<- Tämä tässä on kovin typerä, koska se sarjaliikenne on jo tässä kohdassa nutullaan...
}

Mutta silti siirtäisin ongelman pois Arduinosta. Joku 'buffer overflow' tulee joka tapauksessa ennemmin tai myöhemmin ja se Basic-koodi ei pysty käsittelemään sille tulevaa datamäärää.

Noin yleiseltä kannalta en pidä tuosta ajatuksesta laittaa kaikki toiminnot yhdelle piirikortille. Raskasta jahdata ongelmia kun tietää että vika on siinä kortilla - tai softassa. Ainakin protovaiheessa hajauttaisin kaikki toiminnot kokonaisuuksiin joissa jokaisessa on yksi toiminto ja josta tulee bittidataa ulos. Olisi helpompi hakea vikaa kun voi kytkeä osia pois käytöstä ja käyttöön. Lisäksi olisi ehkä mahdollisuus syöttää systeemille simuloitua dataa ja sillä hakea ongelman aiheuttajaa.

 

[kkuula]

Suurin ongelma tässä on kuten huomasittekin jo tuo SimpleDyno softa ja sen vaatima dataformaatti. Tuohon softaan ei taida harrastajilla olla muita ilmaisia tai edullisia vaihtoehtoja?
Tuossa ESP:ssä ei ole taustalla mitään käyttöjärjestelmää eli ihan kaikki mahdollinen ja mahdottomuus on itse koodaajan kontolla ja päätettävissä kuinka asiat hoidetaan.
Tuosta sarjaliikenteestä sen verran että tässä käytössäni olevassa ESP:llä tehdyssä versiossa en ole havaittu sarjaliikenteessä ongelmia, tuo SimpleDyno softan sarjaliikenne menee vikatilaan jos jos siinä on yksikin bitti vinossa tosin se ei ota kantaa datan sisältöön ollenkaan.

Tässä on pitkä keskustelu tuon softan ongelmista: https://www.kotiverstas.com/keskustelu/index.php?topic=38613.0

Tässä toteutuksessa pulssitaajuus rullan triggeriltä on sen verran alhainen että tällä ESP:llä tai PC softalla ei pitäisi olla mitään ongelmia prosessoida tuota dataa vaikka moneen kertaan.

Tässä nyt tuo softatoteutus on mitä on sekä PC:n puolella että tuon Uc:n puolella ja sehän toimii tällä ESP32 versiolla aina rullan nopeuteen noin 2600...3000rpm asti mikä riittää suurimmalle osalle käyttäjiä.

 

[kymi]

SimpleDynoon on nähdäkseni joku C# variantti olemassa, voi olla ehkä helpommin jatkokäytettävissä, en osaa sanoa.

Adruino/ESP on pohjimmiltaan käyttäjälle kehitysympäristöjä, joten se koodi mitä niihin syötetään on ihan helppokielistä ymmärrettävää ja käännetään koodinsyöttötasolla. Tämä ei todellakaan vastaa mitään konekieliasiaa (vaikka toki loppupeleissä onkin). En tiedä pystyykö tuota ohittamaan ja kirjoittamaan suoraan konekieltä edes taittuvissa osin. Tämä voi ja varmasti osittain vaikuttaa myös lopputulokseen.

Eipä tosiaan tuo sarjaliikenne kyykkää suoranaisesti ongelmista, kyllä se vaatii muuta.

En nyt ala naapurifoorumin juttuja arvioimaan kun en rekisteröitymättä nimimerkkejä näe, mutta suhtautuisin harkiten. On vähän outoja ideoita ilmassa.

 

[kkuula]

Kylä se ongelma tuolla naapurifoorumilla selvitettiin melko pitkälle ja jopa koitti kaveri korjata tuota dynosoftaa tosin laihoin tuloksin. Lopputulema oli että 8bit atmellin uC:lla päästiin samaan lopputulokseen käyttäen rautatason keskeytystä ja laskureita mitä itse pääsin käyttäen tuota ESP:tä suoraan arduino lisukkeiden kanssa. Tästä voitaisiin päätellä että kummallakin sekä ESP Että 8bit atmellin prosessorilla datan lähetys ottaa karkeasti saman verran aikaa. Nyt jos tuosta sarjaliikenteestä saisi ylimääräisen arduino tauhkan ravisteltua pois välistä voisi saada koodin toimimaan vielä pikkusen ylemmille kierroksille.
Arduino ympäristössä aina on sen ympäristön omat käyttöä helpottavat lisukkeet kirjoitetun koodin ja prosessorin välissä mutta ainakin noilla 8bit Atmellin prossuilla voi ohjata suoraan niitä prossun rekistereitä tai jopa kirjoittaa sekaan koodia konekielellä. ESP:stä ei ole tietoa onnistuisiko sama silläkin.

 

[Wictor]

Eikös se ongelma ole tuolla PC:n softassa, jos oikein ymmärsin kotiverstaan tutkimukset.

 

[alfred_j_kwak]

Eikös se ongelma ole tuolla PC:n softassa, jos oikein ymmärsin kotiverstaan tutkimukset.

On. Ja sitä yritetään korjata analogiaelektroniikalla.

 

[JKAVS]

Kuinka merkityksellistä tuo on, että ohjelma toimii reaaliajassa? Minulla on välillä tapana keksiä pyörä uudelleen, mutta helpoimmalta tuntuisi että mittaustilanteessa mikrokontrolleri tallentaisi datan vaikka muistikortille. Muistikortin voisi sitten kiikuttaa tietokoneelle, jossa voisi olla esim. Python-skripti käyrien piirtämistä varten.

 

[kkuula]

Softa löytyy githibista ja siihen passaa tutustua ja ehdottaa korjauksia.
Tuon datan voisi tallentaa Uc:n omaankin muistiin ja tekasta semmonen skripti mikä osaisi vastaanottaa sen datan ja piirtää siitä käppyrät. Ensin pitäisi päättää millaista dataa ja missä muodossa tallennetaan ja missä hoidetaan rullan pyörimusnopeustiedon muutos tehoksi ja vääntömomentiksi ajanjetkellä. Missä ja miten syötettäisiin laskentaa tarvittavat parametrit?

Jos lisätään vaatimuksia, systeemin pitäisi olla mahdollisen mittalaitteen osalta riittävän halpa ja helppokäyttöinen. Käytännössä mittalaite tarvitsisi oman jonkinlaisen käyttöliittymän.

Tuo simple dyno toimii hyvin kunhan pysytään alle tuon edellä esitetyn rullan nopeuden.

Tämän aloittamani keskustelun alkuperäinen ajatus on suunnitella uusi versio tuosta mittakortista eikä korjata tuota softapuolen ongelmaa.

 

[Wictor]

Helpoin tapa on sitten korjata arduinosofta siten, että skippaa vaikka joka toisen pulssin ja konffataan PC-softa puolta pienemmälle pulssimäärälle.

 

[kkuula]

Helpoin tapa on sitten korjata arduinosofta siten, että skippaa vaikka joka toisen pulssin ja konffataan PC-softa puolta pienemmälle pulssimäärälle.

Tämä on varmaan helpoin totutettavissa oleva idea, Dynosofta sallii asetuksissa käyttää rullan pulssimäärällä kierrosta kohden arvoa 0,5 ja mittakortin puolella on helppo jättää jokatoinen pulssi huomiotta.

Täytynee alkaa summamaan mitä muutoksia tuohon uuteen versioon tulisi verrattuna nykyiseen. Ainakin esiintyvä sytytyksen aiheuttamaa häiriötä joka poistuu siirtämällä mittalaite riittävän kauas voisi koittaa labrata johtuuko se itse anturin häiriintymisestä koska sen kaksijohtiminen induktiivinen anturi jota tuossa käytetään ihan alarajalla olevalla käyttöjännitteellä. Kyseistä anturia tuskin on kellään missään muualla joten sen tilalle voisi vaihtaa jonkin autokäyttöön tehdyn hall anturin jolla saisi paremmat signaalitason ja ehkä paremman häiriösietoisuuden. Anturiksi ehkä alkuperäisen ardynon käyttämä honeywell 1GT101DC mitä löytyy autotarvikekaupoista muutamalla kympillä tai jos on ehdottaa jotain vastaavaa?

 

[Jammu]

Kas, tuo vaikuttaa järkevältä.

Aika vähän olen arduinolla tehnyt, töissä jotain ja sen lisäksi yhden kesäpojan arduinokoodiia muokannut. Ne tehtiin kyllä ihan C-kielellä. C on mielestäni hyvä ja pääsee kohtuunopeuksiin mikrokontrolleripuolella. En yhtään ihmettele ettei korkeammalla tasolla oleva koodi sitten enää pelaakaan kun tulee pulssia nopeaan. Mutta parempi etten spekuloi enempiä perehtymättä.

Kuitenkin tosiaan aikakriittiset asiat olisi järkevä mitata siellä mikrokontrollerilla käyttäen mahdollisia hardwarelaskureita. Tuottaa niistä raakadata josta pidemmälle viety laskenta PC-softassa. Toki mm kymin laittama pointti on tärkeä, on helpompi labrata sitä PC softaa kuin hinuttaa mikrokontrolleria kehitysympäristössään.

Keskeytysten käyttö ei mielestäni ole ongelma, itse käyttänyt PIC-puolella, prioriteettiasiat löytyy dokumentaatiosta hyvin, keskeytykset voi sallia ja estää globaalisti jne.

honeywell 1GT101DC on jokseenkin tuttu, tuossa pöydällä edessäni on yksi. Joskus vuonna nakki käytettyy megasquirt-projekteissa kaverin kanssa. En pitäisi huonona muuta kuin kokoa. Hintaa näemmä tullut kai vajaa kymppi lisää. Hall-anturihan tuo on, sisällä heikko magneetti

 

[Juskaks]

Usbissa on oma latenssinsa riippuen ajurista. Joskus yhden tiedonkeruun kanssa debuggailtiin niin windows hid-ajurilla oli ihan merkittävä se pakettilatenssi, ehkä 10ms en enää muista. No se kuitenkin aiheutti tarpeen pakata paljon dataa yhteen usb-pakettiin.

Sarjaporttiemulaatiossa voi hyvin olla sama juttu että ei kannata lähettää tavu kerrallaan.