Page 2 of 3 FirstFirst 123 LastLast
Results 31 to 60 of 84

Thread: DIY Ardunio Project

  1. #31
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    currently my biggest concern is regardless of data capture, how to manage/display/manipulate said data.

    the stuff from GEMS seems pretty good and highly customisable. ive asked for a sample datafile to play with in their non-pro software version, but perhaps their pro-version with CSV input capability (and lots more customisation capability) would be the go, and just suck up the 250gbp to have software that works
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  2. #32
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    Silab or MATLAB is what I use. Excel would be another option.
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  3. #33
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Quote Originally Posted by Jason Broadhurst View Post
    Silab or MATLAB .
    LOL, I think you drastically overestimate the amount of free time I have to learn how to do this
    Last edited by doctor ed; 18-10-17 at 12:06 AM.

  4. #34
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    edit... now im just getting carried away...

    very fucking cool tho



    and the poor mans arduino verion:
    https://www.seeedstudio.com/Grove-Di...or-p-2385.html

    video overlay softare
    http://www.dashware.net/
    Last edited by doctor ed; 18-10-17 at 04:34 AM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  5. #35
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    arduino mega based GPS / MEMS / OBD logger:
    https://freematics.com/store/index.p...&product_id=58



    also the GEMS software data format is pretty nonstandard

    Click image for larger version. 

Name:	Untitled-22.jpg 
Views:	21 
Size:	1.01 MB 
ID:	102617
    Last edited by doctor ed; 18-10-17 at 03:35 AM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  6. #36
    Interested bystander
    Join Date
    Dec 2001
    Location
    Australia
    Posts
    792
    Try displaying it in Hex

  7. #37
    \_(ツ)_/ burn is weird's Avatar
    Join Date
    May 2011
    Location
    gold coast
    Posts
    1,544
    Ok so there is a sneaky way to get the GEMS datalog software (or you can use AEMData, which is AEMs licenced version of the software) to be able to read CSVs without having to licence it.

    see this thread: https://pcmhacking.net/forums/viewto...t=4191&p=54449

    Gems has no video in free version, but if you use the AEM version you have access to video playback (using .webm format) etc, but you will be missing FFT, alarm reports, CSV export and a few other things that are available if you open a log file that was generated by AEM logging hardware, or buy the GEMs licenced version of the software.

    there is a legacy bit of software that used to be gems logging software, called DLOG99. it used to be on their website but has since been removed as i guess they saw the loophole. try googling to see if you can find it anywhere or if you PM me an email I can send you the installer file.

    but basically you open DLOG99, and import a CSV, tell it which row contains all the channel labels and then it will create an STF file that can be imported in the free version of GEMS data analysis software. you don't have any maths channels though so I just use an excel script to apply any math I want to the CSV file before converting it.

    alternatively, megalog viewer is a cheap bit of software that is pretty powerful and will let you apply maths to a datalog, no video support though.
    Last edited by burn is weird; 18-10-17 at 02:01 PM.

    Oo___oO


  8. #38
    \_(ツ)_/ burn is weird's Avatar
    Join Date
    May 2011
    Location
    gold coast
    Posts
    1,544
    a reasonably inexpensive way into the AEM version of the software (which does not support CSVs, so you need to use the DLOG99 trick) is one of these.

    http://www.jegs.com/i/AEM/017/30-2500/10002/-1

    which supports CAN interfacing so you can just log CAN parameters from your ecu of choice, or wire sensors to it if you like, but I'd take all of them to the ECU instead. has accelerometer on board and an RS232 connection for NMEA GPS unit which is pretty useful.
    Last edited by burn is weird; 18-10-17 at 02:16 PM.

    Oo___oO


  9. #39
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Thats the best news Ive read all week

    fyi:
    -----
    I managed to open csv data from Race Capture Pro with GDA (not the pro version). Very Happy

    Here is how :
    * Open your CSV data with excel (or another spreadsheet)
    * Place the time row in first position
    * Make the time start at 0 (substract each cell with the first time)
    * Change each column title to have only the name with brackets ** (eg : "Speed")

    * import your modified CSV into Gems DLog99 (freely downloadable on their website)
    * save the project (this will create a .stf file)

    * Open this file with the latest version of GDA

    ----

    ** i think by brackets they mean quotes "xxx"
    Last edited by doctor ed; 19-10-17 at 06:06 AM.

  10. #40
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Quote Originally Posted by burn is weird View Post
    alternatively, megalog viewer is a cheap bit of software that is pretty powerful and will let you apply maths to a datalog, no video support though.
    http://www.efianalytics.com/MegaLogViewerHD/

    also pretty damn convincing without the conversion fuckaround

    also a rather depressing read about arduino's as loggers

    http://www.f1technical.net/forum/vie...24813&start=30

    faster ADC shield:
    http://mayhewlabs.com/products/extended-adc-shield
    Last edited by doctor ed; 19-10-17 at 07:03 AM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  11. #41
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    so threw the idea at a few bob vegenas on fiverr... lots of bites, and according to sunjeet and co. it should be easily doable, and cost for writing and proofing the code, along with followup support would only be US$100-150

    not shabby if infact they pull it off. i think im realising slowly that learning to program, and trying to pull this off as a one-off might be a bit ambitious

    probably only looking at 10Hz actual logging though. the ADC for the suspension would be something like 1kHz but due to snycing of the various sensors, the output gets truncated to the slowest. whether than means the 1kHz gets averaged to 10Kz, or a single digit is pulled at 10Hz i have no idea.

    i did look at some sample data streams at 10Hz though, and even the suspension data was pretty usable i thought.

    Edit, one bloke from Pakistan reckons he can get it all working and logging st 100Hz, though the GPS data will only update at 10Hz. He wants more like US$250 but seems like he knows his shit, and guarantees itll work...

    Would put total cost at around $500

    Current proposed setup:
    1x - GPS logging
    1x - 3 axis accelerometer/gyro logging
    8x - IR Temp Sensor logging
    4x - analogue 0-5V input logging (output from 5kohm Rotary Potentiometer)

    Rotary pot for the suspension movement sensor side of things:
    https://www.modificars.fi/Dokumentit/0280122001.pdf

    So found some cheap excess stock of IR temp sensors in Romania... lol.

    Genuine MLX90614ESF - ACC 5V 35deg FOV. Perfect. Got 10 of them for US$40 they're an I2C thing, and they're fixed address, so need to run them through a multiplexer to avoid address conflicts. No idea what that'll mean to logging frequency, but we'll see I guess.

    Easy choice would be to mount fixed in the wheel arch at the back of the wheel (about 6-7cm from tyre) and capture 2 segments - inside-middle of the tread, as well as outside-middle. 2 sensors would cover 2 strips of say 30mm of tyre face each. Steering angles aren't generally huge, so most of the tyre would stay in sensor range most of the time, and more importantly distance from sensor to tyre stays pretty constant.

    The temp logging is actually quite an exciting idea. Beats the hell out of running around with the temp gun on half cooled tyres back in the garage
    Last edited by doctor ed; 20-10-17 at 03:50 AM.

  12. #42
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    interesting.... i have a random .csv here which i managed to manually reformat so it would import smoothly into dlog99... output from dlog99 to .stf, all ok, but then go to import that .stf into GEMS Data and it has a heart attack and crashes (version 4.01.32)

    same .stf file imported into AEM Data (version 4.01.30) and voila! everything is fine
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  13. #43
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    So... I ended up booking a chick (nopics... yet) to do the coding/proofing etc for $150. current materials estimate is also ~ $150 so looking at a $300 total project cost.

    Basic layout as follows

    Temp sensors:
    - 3x 35deg FOV IR temp sensors for each wheel (MLX90614ESF-ACC) running on the i2c bus
    - left and right wheels grouped into a bundle of 6 sensors managed by a local i2c multiplexer
    - one multiplexer front and rear to give a total of 2 groups of 6 sensors (12 i2c IR sensors in total)

    Suspension position sensors:
    - 4x Analogue Bosch 0280122001 3 -Pin TPS sensors. Basically a 2kohm variable pot giving 0-5V output over 90deg sweep

    Accelerometer/Gyro:
    - again on the i2c, digital MEMS/Gyro from https://www.sparkfun.com/products/11977

    GPS
    - haven't settled in this yet, but fairly standard 10Hz GPS

    The i2c bus and the ADC channels can be logged at 100Hz, the GPS also logged at 100Hz but data only gets updated at 10Hz.

    Possible issue is going to be running cable for the i2c temp sensors. As they're likely going to be 2m from the arduino, there's potential for signal loss, cross talk etc etc. need to get some good shielded twist Strand cable, and then there's weird shit about adding caps, different pull-up resistors, playing with baud rate and god know what that I don't understand. Plus... does having a multiplexer half way along the line essentially act as a relay post and reconditions the signal? Cuts the the wire distance effectively in half, so I assume there's less likelihood of signal issues?

    Def worth having a crack though!

    Click image for larger version. 

Name:	IMG_0295.JPG 
Views:	18 
Size:	128.1 KB 
ID:	102673
    Last edited by doctor ed; 20-10-17 at 08:18 PM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  14. #44
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Potential choice of wire to maximise the i2c signal range to the IR temp sensors -
    15pF/ft - https://www.distrelec.de/Web/Downloa...24_1PR_eng.pdf



    And if that's doesn't work... i2c range extender/signal conditioner -
    http://sandboxelectronics.com/?p=289
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  15. #45
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    i2c will be fine for a few meters with properly shielded cable, just reduce your baud rate until it's stable.

    Shield is to be earthed at only one end, to the chassis. if you earth both ends you will end up with lots of problems.

    The cable you want is will be called "Single Pair Shielded Twisted Pair, 0.5 mm", although the conductor cross sectional area (CSA) of 0.5 mm is just a preference thing, smaller may work better for small components. Single pair "STP 0.5 mm"

    It may also be called Single Pair Overall Screened or "OAS 0.5 mm"

    Any electrical wholesaler will have that gear and it's cheap @ << $1/m.

    FYI that "DeviceNET" cable you posted is for Allen Bradley PLC's and remote IO. It's massive overkill for your purpose. For your distance, two straightened out coat hangers would work. That cable is for DeviceNET that spans the theoretical limit distance and still function to an OEM specified level. DeviceNET equipment on my bench is using chopped up extension lead due to the distance not being a problem.
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  16. #46
    Registered User
    Join Date
    Mar 2005
    Location
    wollongong
    Posts
    966
    Quote Originally Posted by doctor ed View Post
    though the GPS data will only update at 10Hz.
    That is the basic default sampling for GPS for us plebs. I think Motec had a go at 20hz and it was not successful but I might be wrong there. The major problem with good data logging is the software and how good it is. Getting the data is a fairly simple process, getting the software to tell you what you need to know is the trick. We ran GPS parallel with physical sensors including timing to compare and the GPS always lagged but I have been out of it for a few years now so things might have changed. I had track maps of Wakefield that went through the carports which was not too helpful.

  17. #47
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    FYI that "DeviceNET" cable you posted is for Allen Bradley PLC's and remote IO. It's massive overkill for your purpose. For your distance, two straightened out coat hangers would work. That cable is for DeviceNET that spans the theoretical limit distance and still function to an OEM specified level. DeviceNET equipment on my bench is using chopped up extension lead due to the distance not being a problem.
    Overkill... but overkill in a good way? I can get the cable for cheap locally, so if its overkill but good overkill... is there anything actually against using it?
    Last edited by doctor ed; 22-10-17 at 11:52 PM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  18. #48
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    It'll be a pain in the neck to terminate, and doesn't have a trace through the shielding like proper cable. The trace is an actual wire you can run to the chassis. That cable relies on the plug to contact the foil shield and earth.

    You could make it work no problem at all so long as you can terminate the conductors and earth the trace.
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  19. #49
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    ok, theyve also got this... with a 22AWG drainwire for the shielding... https://www.distrelec.de/Web/Downloa...4A_eng_tds.pdf

    And just a quick question on terminating at plugs etc. I got a bunch of superseal multipin connectors which I was thinking of using. Would these be ok, or should I try and acoid plugs/connections as afar as possible?
    Last edited by doctor ed; 23-10-17 at 06:35 AM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  20. #50
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    Why are you looking 2 pair? Do you need 4 conductors?

    Superseal will be good mate, just make sure you carry the shield through a position on the plug.
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  21. #51
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    That will be good for power plus ic, each pair is individually screened so perfect.
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  22. #52
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Awesome, thanks for the tips. Steep learning curve here

    current hardware list...

    - Arduino (genuine) Mega R3
    - DSSC0124 GPS i2c
    - Adafruit 1141 SD logger shield
    - Adafruit ADXL345 i2c 3axis Accelerometer
    - Adafruit TCA9548A i2c multiplexer (x2)

    Sensors:
    - x4 Bosch 0280122001 TPS 0-5V
    - x12 Temp Sensor MLX90614ESF-ACC

    Decided to go with a somewhat rare i2c gps board. Means theres no issues trying to time the gps with the other i2c sensors. Programmer chick looked at the data rate coming in over i2c from all the sensors and reckons were well safe for 100hz logging all channels.

    Looking good
    Last edited by doctor ed; 23-10-17 at 06:07 PM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  23. #53
    Registered User
    Join Date
    Jun 2013
    Location
    Australia
    Posts
    112
    Watching this one with interest...

  24. #54
    Registered User
    Join Date
    Jan 2017
    Location
    perth
    Posts
    4
    Having built a number of arduino based loggers over the years, its a great platform for easy development. My current logger records directly to TunerPro format XDL files, can then export to AEM using that excel macro you found. Speed is not a concern for writing to the SD card these days, have had 100Hz record rate no problem. The latest one using a Teensy3 takes vehicle data from the ALDL bus (early commodore), innovate (up to 32 devices on that bus) or other serial streams, flex fuel sensor, and a bunch of analog and digital inputs combining it all in to one data stream.

    One thing worth doing is to over sample your analog inputs and average the readings before saving at your desired sample rate. The arduino is noisy and the 1024 bit resolution is not a usable 10bits. If you over sample its possible to get the full 10bits, accuracy is a different story. If you want that it might be worth using the analog reference input.

  25. #55
    \_(ツ)_/ burn is weird's Avatar
    Join Date
    May 2011
    Location
    gold coast
    Posts
    1,544
    Quote Originally Posted by Mini View Post
    That is the basic default sampling for GPS for us plebs. I think Motec had a go at 20hz and it was not successful but I might be wrong there. The major problem with good data logging is the software and how good it is. Getting the data is a fairly simple process, getting the software to tell you what you need to know is the trick. We ran GPS parallel with physical sensors including timing to compare and the GPS always lagged but I have been out of it for a few years now so things might have changed. I had track maps of Wakefield that went through the carports which was not too helpful.
    once you start cranking up the data rate of GPS past 10hz it becomes very noisy. so noisy the rate of change data from the GPS unit is useless. usually you are better off with 10hz GPS and then use Inertial correction from the accellerometer to interpolate between samples as fast as you like, a bit like a dead reckoning GPS solution.

    also, most GPS chips only output NMEA strings in ascii over serial. which is slow and wasteful if you only want a couple of values of the string, which makes 20-50hz nearly impossible. you need one you can either configure or send requests rather than using the NMEA broadcast.

    to make fast GPS data useful you need to apply something called a Kalman Filter. this is EXTREMELY mathematically intensive for a little microcontroller. it involves some serious matrix manipulation of a rolling dataset.
    Last edited by burn is weird; 24-10-17 at 10:53 AM.

    Oo___oO


  26. #56
    \_(ツ)_/ burn is weird's Avatar
    Join Date
    May 2011
    Location
    gold coast
    Posts
    1,544
    STOP EVERYTHING AND BUY ONE OF THESE and a Teensy.

    here is a nice neat shield that has 50hz GPS, CAN Tranceiver and a 9 DOF MEMS chip. AND a SD card slot. this is a nice bit of gear.

    http://www.smokingresistor.com/produ...ps-shield-can/

    here is a project or someone using one with 50hz gps, kalman filtering and CAN logging.

    https://github.com/smokingresistor/TeensyGPS
    Last edited by burn is weird; 24-10-17 at 10:56 AM.

    Oo___oO


  27. #57
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Quote Originally Posted by VL400 View Post
    One thing worth doing is to over sample your analog inputs and average the readings before saving at your desired sample rate. The arduino is noisy and the 1024 bit resolution is not a usable 10bits. If you over sample its possible to get the full 10bits, accuracy is a different story. If you want that it might be worth using the analog reference input.
    You talking about doing the maths on board before saving to the SD card, or post processing of the data on the pc?

    Not sure how much time we have at 100Hz to do onboard maths, but Ill ask.
    Last edited by doctor ed; 24-10-17 at 04:40 PM.
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  28. #58
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    Quote Originally Posted by burn is weird View Post
    STOP EVERYTHING AND BUY ONE OF THESE and a Teensy.
    Boat has sailed on the hardware for now. Lets just get it working here first, then you smart people can adapt it to the teensy if it looks promising
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

  29. #59
    Purist, whats that? Jason Broadhurst's Avatar
    Join Date
    Nov 2003
    Location
    North Brisbane
    Posts
    6,342
    Quote Originally Posted by doctor ed View Post
    You talking about doing the maths on board before saving to the SD card, or post processing of the data on the pc?

    Not sure how much time we have at 100Hz to do onboard maths, but Ill ask.
    He means the ASCII output of the GPS contains A LOT of data. Time, long, lat, age, altitude, course, speed sat info, etc etc. You have to handle that in the microcontroller and then pass it to the logger.

    At 9600 baud(which is 9600 1 or 0 per second) and assuming each 10 of those items is a 8 char asci code you end up with 15 (data points) x 8 (characters) x 8(bits per character for ascii) which equals = 960 bits to transmit, so lets round that up to 1000 bits per sample. You've already maxed 9600 baud at 10 hz sampling.

    Cut that bullshit ascii output down to 1 or 2 values transferred as binary and you can significantly decrease the required bits for the selected data pertinent to your logging. speed as integer would be 16 bits, as would most variables even if you needed a decimal place (you would just have fixed scaling implemented)

    Fun stuff
    Jason Broadhurst

    Someone once asked me if they could use my mower. I said "sure, so long as it doesn't leave my yard"

  30. #60
    GTFO of my ED doctor ed's Avatar
    Join Date
    Jun 2002
    Location
    irgendwo
    Posts
    4,077
    I thought he was talking about noise in the analogue sensor data, and oversampling at say 400Hz and logging a calculated average at 100Hz or something? Didnt see where GPS came into it?

    GPS is another thing altogether... as you point out
    Mit freundlichen Gre

    Quote Originally Posted by Keith Duckworth View Post
    "I think that in a racing engine, the closer it is to disintegrating, in general the better its performance will be "

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •