Announcement

Collapse
No announcement yet.

DIY Ardunio Project

Collapse
X
Collapse
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #31
    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

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

    Comment


      #32
      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"

      Comment


        #33
        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
        Mit freundlichen Gre

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

        Comment


          #34
          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/
          Mit freundlichen Gre

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

          Comment


            #35
            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 :w:

            Click image for larger version

Name:	Untitled-22.jpg
Views:	1
Size:	1.01 MB
ID:	6611106
            Mit freundlichen Gre

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

            Comment


              #36
              Try displaying it in Hex

              Comment


                #37
                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.

                Oo___oO

                Comment


                  #38
                  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.

                  Oo___oO

                  Comment


                    #39
                    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"
                    Mit freundlichen Gre

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

                    Comment


                      #40
                      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
                      Mit freundlichen Gre

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

                      Comment


                        #41
                        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
                        Mit freundlichen Gre

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

                        Comment


                          #42
                          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

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

                          Comment


                            #43
                            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:	1
Size:	128.1 KB
ID:	6611157
                            Mit freundlichen Gre

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

                            Comment


                              #44
                              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

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

                              Comment


                                #45
                                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"

                                Comment

                                Working...
                                X