I am trying to make an arduino that uses the 9DOF to accurately record data. So far the parts I am looking at using are: 1) The Arduino Uno(would the Arduino Due work better here since it has a faster clock speed?), 2) The 9DOF board, I need to use all 9 degrees here!, 3) The Data Logger - Atlas Scientific ENV-32X(what I want to datalog with), 4)Breakout Board for microSD Transflash(biggest thing I am not sure about, will explain requirements later)(<---- no longer used, see edit), 5) The Momentary Button - Panel Mount (Green)
My goal here is to record the data given by the 9DOF, reformat it to fit in the 128 character limit of the ENV-32X, and then send it over to the ENV and do all of this while getting a stream of data from all of this and getting multiple reading a second, I need to have split second data because it is going to be used on a racecar :auto-car: :auto-layrubber: :dance:. I would like to be able to hit the button, the momentary panel mount one, to start and end the datalog session, and at the end of the session send all of that formatted data over to an SD card, issue that I will now discuss. I just choose that microSD one because I thought it might work, idk if it actually will, and because I would prefer a normal sized SD version that allows the card to have data stored onto it, if I choose the wrong item please help I wasn’t sure what to search for or look for to do this. :?
Basically what I am asking for is how to wire the SD card saving part and how to make the data logging begin at the push of a button, end and save the data with the next push of the button. Thank you for any help that y’all can provide!
EDIT:
Okay so I found a better way to save data to the SD card, I will use the “microSD Shield”, still not a full size SD card but I guess a microSD card will be okay with me. Now my biggest question, is all of what I want to do possible? as in compatible and able to work as defined above? Now that I have the data logger, 9DOF, and the microSD Shield picked out, will they interface nicely? or will it require some work around? Please if you have an ideas reply soon as I will be leaving the country in a couple weeks and I need to have this figured out before then if at all possible. Thank y’all for any help!!!
You’ve left out a couple of key requirements needed to assess the scheme. How fast (samples/sec) do you need the data sampled ? For how long ? It’s one thing to log for a drag race, another for the Indy 500. Are there other items you’ll want to log, throttle position, engine RPM, ??? Do you want to add a GPS into the mix ?
The logger is an odd beast. It wants 128 character strings and will log only 32k of them. It’s interface is RS-232 but at 0-TTL levels. I don’t know if this means some additional hardware between the Uno and logger, or just some software complements. I wasn’t able to find (in my brief look-see) the max bit rate it’ll support and that may limit the number of items sampled and/or their sampling rate. It’s no good to collect data faster than you can x-fer it to the logger. I suspect you’ll end up emulating a serial port via SoftSerial to send data to the logger. That has a max working limit
In general I don’t see any major hangups but some questions to be answered. I don’t see much use for the magnetometer data and I suspect getting it to work well within a steel car would be a PITA. Once you’ve settled on a sample rate and know the logger will support that rate for the time needed then you need to come up with a schedule of things the UNO has to do and then see if that’s possible.
ie - if the sample rate is 50x/sec for all data items and those are X, Y and Z acceleration and gyro data then every 0.02 secs the UNO must;
read the 6 items from the 9DOF
reconstruct (if needed) each single data item and format it for logging
VCC: 2.5 - 3.6 volts. Voltages above 3.6 volts will damage the ENV-32X TX: TX output delivers asynchronous serial data in TTL RS232 format, except voltages are 0-Vcc. All data output ends with a carriage return (ASCII 13). The baud rate is: 38400, 8 bits, no parity, with one stop bit. The voltage swing 0-VCC, not +/- 12 volts If standard voltage level RS232 is desired, connect an RS232 converter such as a MAX232.
So each character sent takes ~260 usec, the whole 128 character string (including control characters) is then ~33.9 msec … longer than allowed by a 50 Hz sampling rate. So some caution is needed.
I get the impression from the above that the input is just TTL serial not some odd version of RS232. Note that the device runs at 3.3v and so a level shifter may be needed to go between the UNO and logger.
Which 9DOF board? Sparkfun sells at least four different models.
Why are you using both the ENV-32X and an SD card? It seems like they provide redundant capabilities. I recently made a similar project, logging 3-axis accel data to an SD card. Using standard Arduino libraries, I recorded nicely formatted text at 50 Hz, but that was pushing it.
I don’t necessarily recommend this path, but by doing some ugly hacks to the code for the adafruit wave shield, 800 Hz (4800 bytes per second) was no problem at all.
Okay to answer some questions and to clarify( I AM NEW TO ARDUINO’S!!!, please make this easier to understand for me, I have programmed, and built electronics, but never together so I am not used to logic via this manner).
To Mee_n_Mac, I need more information that I understand here, what is a level shifter? I would like to sample about 30x/sec or possibly a little faster, max is what can be handled reliably. I will be data logging for up to 14 miles of data, but that is only one time that it would have to do that, which may not be possible to log all in one go, but we have a driver swap half way into that, we could hit the button, let in transfer(how long would we need to wait for this?) and then log again. Thanks for pointing out the whole magnetometer thing, forgot about the fact the car was steel, I was wanting it because it would tell if we were turning and to which Direction we were heading to make the data a bit easier to understand.
To sethcim, I was going to use the sensor stick version, maybe not anymore because I might just use the 6DOF. I need the SD card to save data to because the arduino will always stay on the car, and it would be easier to have to never mess with it in order to make sure we don’t fill it up. And so that we have data logs from each person, or day separately stored. Could you send me a link for those projects? I would like to see if I could use that project for ideas.
A level shifter is a device that converts signal levels from one voltage level to another and visa-verse (ie - 3.3V to 5V in your case), needed if you use a UNO and that logger as the UNO is a 5V device w/5V IO pins and the logger is a 3.3V device w/3.3V IO pins. Now you might go to a 3.3V version of some Arduino (I won’t get specific yet) and eliminate this. I forget what voltage SD cards (or any similar device) operates at and (of course) what voltage the 9DOF (or 6DOF) run at. Ideally they all run at the same voltage and there’s no need for any level “shifting” but sometimes there’s just no way to avoid it. The point being … choose your components w/this thought in mind, evven if it’s not the top priority.
So how long, approximately, will it take to run the 14 miles ?
…The one thing I forgot…time facepalm, it all depends on how they drive and what the conditions are, if I say it is an average of 75 seconds a lap, with 28 laps, it should be, average, 17.5 minutes, if we datalog in two segments, it would be very manageable, otherwise there is a risk of overrunning the limit, at least with 30x/sec, which has a limit of 18.2 minutes.
I know the Arduino Due is supposed to be a 3.3V logic based microcontroller, at least that is what I understand from the info. on sparkfun’s listing. I know the Atlas data logger, and the 6DOF are 3.3v devices, but I can’t tell with the microSD shield, it says it bring down the 5v inputs down to 3.3v, but I don’t know if it will be able to work with a 3.3v device straight up, or could I use the Due’s “5V” input?
BTW, Thank you for your help so far, I appreciate that someone is taking out some time to help me understand this stuff better.
First order of business is to decide which device (ENV-32X or SD card) to use for storage. I don’t see much benefit to using them both; in fact trying to transfer between the two might be the hardest part of the project. Here are the characteristics of each, as I see them:
ENV-32X has limited memory, good for about 18 minutes (32,000 samples / 30 samples per second / 60 seconds per minute)
easy to write to using print statements to software serial. I can’t speak to the limitations of software serial
harder to read back - you have to copy the output from one serial port to another, or use a USB-to-serial adapter
SD card has practically unlimited memory
Writing incurs a lot of overhead - there can be dropped samples due to write latency if you try to go too fast, and the code libraries for dealing with the file system use up half your code space.
Reading is easy - pop the card into your computer
We’re mentioning software serial because the UNO has only one hardware serial port. That is, a dedicated circuit on the arduino chip for communicating with other electronics. It’s often used to talk to the computer running the Arduino IDE, so you might end up using a library (softserial) that uses software code to produce the same result on any pin. It comes at a cost of more computation competing for resources.
Write latency - SD cards are made for handling large amounts of data, so they are happier writing a huge chunk every now and then, than a hundred bytes every 10 milliseconds. There can be erratic delays due to this process, which are partly helped by getting certain, fast cards.
You might also want to look at the OpenLog, especially since there is already a complete example program interfacing the 9DOF sensor stick with it. https://github.com/petmar0/IMU9DOF_Logger
The OpenLog looks pretty cool actually, so basically all I would have to do is get the OpenLog, the 6DOF, a microSD card and an arduino and I would be able to datalog? Is there a way to make this all stop and start at the press of a button given that code you sent me? and what baud rate would you recommend for fast data collection with low package loss? From what I read on the wiki the OpenLog supports SDHC? This could help a lot with package loss due to overrunning the buffer. Now does the code send all of this data to a .txt file? or is there a way to save it to a .csv? The ECU we use datalogs in this format, if you were wondering why the 6DOF is separate from the ECU datalog abilities, we ran out of inputs on the ECU for data logging capabilities…
EDIT:
I was also thinking of using this button https://www.sparkfun.com/products/11972, which is a latching button, could I hook this up to something that starts a power off sequence for the OpenLog? as in could it stop the datalog, allowing everything to be saved, and then power off after? Thank you for y’all’s help!!!
BlindAssassin111:
The OpenLog looks pretty cool actually, so basically all I would have to do is get the OpenLog, the 6DOF, a microSD card and an arduino and I would be able to datalog?
I think so.
BlindAssassin111:
Is there a way to make this all stop and start at the press of a button given that code you sent me?
Yup. You just have to program the Arduino to read the switch/button input and act accordingly.
BlindAssassin111:
and what baud rate would you recommend for fast data collection with low package loss?
I'm not sure but with the logger close to the Arduino, you might manage 115k w/o a problem. Frankly I would use a rate just high enough to work.
BlindAssassin111:
Now does the code send all of this data to a .txt file? or is there a way to save it to a .csv?
As I understand it the logger stores the data in a .txt file. If you want commas to delimit the data, code the Arduino to put them in, btw the samples, before it sends them to the logger.
Pertaining to the BAUD rate question above and just for ease of making things work and given the OpenLog is not an Arduino shield form factor (nor are any of the SFE 6DOF or 9DOF boards) … I would recommend not using an UNO but instead going to a 32U4 based Arduino (a Pro Micro would be one such Arduino). They have a free UART since the USB connection is “built in”. This way you don’t have to use SoftSerial to send data to the logger and don’t have to worry about interrupts clobbering the communications to/from the 6/9DOF board. If you think you might expand the data collected, even a MEGA Arduino might be worth a look. Design first, buy third. Just a thought …
Lastly re: 6DOF vs 9DOF … I wouldn’t worry about 6 vs 9 so much as getting the gyros and accels you need for your task. Make sure they have the proper range and desired sensitivity and accuracy and needed update rate(s). Think about how you’ll time getting data from the devices; a board that issues interrupts makes timing a trivial issue vs one that doesn’t. You may find that the magnetometer comes for free (or little added $s) and perhaps some day you’ll be tempted to see if it can work.
So I would prefer to use the MEGA, because we will over time expand upon what we datalog with this method. Okay so now comes the part that I really need help on, if I were to use a latching button to start the datalog, on both the ECU, which uses a ground-out style of start, and the arduino, would this be possible to use one switch to ground out both and not have any issues? Also, how would I code the button in? I was looking for examples on how to add a button in to something like this but the threads died before an answer was given.
What does a UART do for me? As in how does it make it better for what I am doing, compared to an UNO?
In regards to the 9DOF(decided to see if the magnetometer will work correctly, worth a shot!!!), I am trying to draw up how to connect all of this together, would you know what VCC it needs? I can’t seem to find it anywhere. Also, why does the mega have two sets of SDA and SCL, are both able to be used separately?
They have a free UART since the USB connection is “built in”. This way you don’t have to use SoftSerial to send data to the logger and don’t have to worry about interrupts clobbering the communications to/from the 6/9DOF board.
Didn’t Mee_n_Mac already explain here what the reason for it’s preference was?
Also, why does the mega have two sets of SDA and SCL, are both able to be used separately?
They have a free UART since the USB connection is “built in”. This way you don’t have to use SoftSerial to send data to the logger and don’t have to worry about interrupts clobbering the communications to/from the 6/9DOF board.
Didn’t Mee_n_Mac already explain here what the pro was?[/quote]
…You have no reason to be an ass. I looked up what a UART was before posting that comment, I was asking why it would be better for what I am doing, i.e. why it is better to use a MEGA or a pro micro vs. the UNO, for my data logging needs. Plus he was being helpful and explaining what is good about a pro micro, which I wasn’t sure why I was being told it is better to switch over when others have just used the UNO for this type of process.
Now if you have nothing useful to input, please leave, as you have neither helped nor have you been courteous to new users of this forum and arduino’s. Thank you and have a nice day!](http://lmgtfy.com/?q=uart)
BlindAssassin111:
…You have no reason to be an ass. I looked up what a UART was before posting that comment, I was asking why it would be better for what I am doing, i.e. why it is better to use a MEGA or a pro micro vs. the UNO, for my data logging needs. Plus he was being helpful and explaining what is good about a pro micro, which I wasn’t sure why I was being told it is better to switch over when others have just used the UNO for this type of process.
I can repeat my earlier reply. But you might have missed my edit a few seconds before yours. Mee_n_mac’s post contains the answers that you seek. In other words: Dual hardware serial connections (one normal serial port and one as part of the USB connection) do not interfere with each other and your program flow. A simulated serial port based on time-critical interrupts detecting each serial bit would.
Now if you have nothing useful to input, please leave, as you have neither helped nor have you been courteous to new users of this forum and arduino’s. Thank you and have a nice day!
I try to show how new users can figure out what goes wrong in their project. Or at least get more insight in what is going on that they can’t see yet. Yeah, I don’t usually spoon feed the solution. It’s a different kind of helpful. Teaching where to look. And I guess I lack the people skills a bit. I usually forgo the welcoming part. I focus on the subject at hand. That’s why they come here don’t they?
BlindAssassin111:
…You have no reason to be an ass. I looked up what a UART was before posting that comment, I was asking why it would be better for what I am doing, i.e. why it is better to use a MEGA or a pro micro vs. the UNO, for my data logging needs. Plus he was being helpful and explaining what is good about a pro micro, which I wasn’t sure why I was being told it is better to switch over when others have just used the UNO for this type of process.
I can repeat my earlier reply. But you might have missed my edit a few seconds before yours. Mee_n_mac’s post contains the answers that you seek. In other words: Dual hardware serial connections (one normal serial port and one as part of the USB connection) do not interfere with each other and your program flow. A simulated serial port based on time-critical interrupts detecting each serial bit would.
Now if you have nothing useful to input, please leave, as you have neither helped nor have you been courteous to new users of this forum and arduino’s. Thank you and have a nice day!
I try to show how new users can figure out what goes wrong in their project. Or at least get more insight in what is going on that they can’t see yet. Yeah, I don’t usually spoon feed the solution. It’s a different kind of helpful. Teaching where to look. And I guess I lack the people skills a bit. I usually forgo the welcoming part. I focus on the subject at hand. That’s why they come here don’t they?
Okay that is much better!! I understand it more now (no sarcasm) So basically the MEGA has none simulated ports allowing faster, more reliable data interface? If so, that justifies the added cost for what I will be using it for. Now, if you would be so kind as to help a little bit more, Can you answer this, Please?
(from my earlier post)
“Okay so now comes the part that I really need help on, if I were to use a latching button to start the datalog, on both the ECU, which uses a ground-out style of start, and the arduino, would this be possible to use one switch to ground out both and not have any issues? Also, how would I code the button in? I was looking for examples on how to add a button in to something like this but the threads died before an answer was given.”
I appreciate all help given, even if it was not spoon-fed to me, I have searched but I am not the best, seeing as I am new.
EDIT:
In the wiring diagram, the one with the actual wires, on the tutorial for the OpenLog(https://www.sparkfun.com/tutorials/393), for some reason only the RX from the OpenLog is connected, is that a mistake? Aren’t both TX and RX supposed to be connected? Besides that, is the diagram correct?
BlindAssassin111:
Okay that is much better!! I understand it more now (no sarcasm) So basically the MEGA has none simulated ports allowing faster, more reliable data interface?
Well, the MEGA microcontroller chip has a handful of serial ports, enough that you do not need to use the SoftSerial library to simulate them. The MEGA has a gazillion pins on which you could assign multiple simulated serial ports. (though there are and interupt and timer resource restrictions also iirc, not just pins)
If so, that justifies the added cost for what I will be using it for. Now, if you would be so kind as to help a little bit more, Can you answer this, Please?
“Justifies” depends on how big your wallet is. The MEGA is a model that you need it you expect major feature creep in your project, or maximum future expandability. But I suspect you could do with the models suggested by Mee_n_mac if you limit your project to what you thus far established. But if you just want to get the biggest and not necessarily sufficient model then I’m sure Sparkfun won’t complain.
I’m sorry I cannot respond more. It is well past 3 am here now. Got to go find my pillow. I do not want to create more misunderstandings.
BlindAssassin111:
“Okay so now comes the part that I really need help on, if I were to use a latching button to start the datalog, on both the ECU, which uses a ground-out style of start, and the arduino, would this be possible to use one switch to ground out both and not have any issues? Also, how would I code the button in? I was looking for examples on how to add a button in to something like this but the threads died before an answer was given.”
It all depends. Not knowing anything about the ECU input pin that you're grounding (perhaps it's pulled up to 12v), I would opt for a 2 pole switch (or 2 separate switches) and keep the electrical systems separate.
In the wiring diagram, the one with the actual wires, on the tutorial for the OpenLog(https://www.sparkfun.com/tutorials/393), for some reason only the RX from the OpenLog is connected, is that a mistake? Aren’t both TX and RX supposed to be connected? Besides that, is the diagram correct?
To log data to the OpenLog you only need to connect the transmit out (Tx-O) of the sending device (your Arduino) to the receive in (Rx-I) of the OpenLog. The Arduino won't be able to "see" any of the responses that the OpenLog may send but often that just doesn't matter. If you want/need your Arduino to read from the OpenLog or see it's responses to commands, then you need to connect the other wire/data path.