I've been digging around for a while trying to figure out a good way to do datalogging with NXT-G. Brian's old post was a good read, but was a little bit complicated at first glance. What I was after was the simplest solution that a teacher could not only implement but also easily understand.
So using the simple file write command, I threw together the following program.
It takes a reading of a timer, uses the 'number to text' to concatenate it with a rotation sensor output with a comma in between and then places it in a log file. It repeates this as often as possible. I found I needed to put a time stamp in, as Brian found, the processors tends to wander off every now and then to proccess some other info. Having the time stamp keeps the data valid even though the sampling rate is not perfectly consistant.
I ran the program on the TI-56 arm and manually opened and closed the gripper a few times.
Data file was then uploaded from the NXT and opened in Excel.
So what did I get?
I was pretty happy with the data. Sure there are sampling rate issues, but as a cheap datalogger I was very happy with it.
Closer inspection of the sampling rate showed just what is happening. With a quick Excel formula (sample time - old sample time) I could graph the time taken between each sample.
It's pretty consistant at 200Hz sampling rate with a regular blip about every 200ms where there is a gap of 11ms, and a more infrequent but larger gap of around 60ms about once a second.
So is it usable? For a primary or middle schools implementation, I think it's great. Kids can learn about datalogging and get into the issues of "what do I log?" and "how often do I sample?" and still get vey useful data.
Stay tuned for part 2 where I have a go at sampling up to 4 sensors at once to see what the effect is. I'm also planning to dump the commas, and process the data in excel, a little more tedius but may give faster sample times.
--
Damien Kee
edit: Thanks Brian for explaining 'why' there are the delays
"1) The short spikes to 10 ms are when the FW writes the accumulated data to FLASH. It does not write every time a File Access block requests it, instead "saving up" data until a block of FLASH can be written at once (causing the delay).
2) The longer spikes are *probably* associated with copying the entire growing text file to a new place in memory. But I'm not yet sure.
3) Eliminating the commas doesn't really gain you much. Since each comma is a single character, but the data is generally 3 or 4 charecters (or more - numbers in text files are stored as, well, text), it reduces the amount that needs to be written... but not very much.
4) Ideally, you should make sure you are opening a "clean" file, and close it at the end of a session. Odd things can happen sometimes if you don't."
So using the simple file write command, I threw together the following program.
It takes a reading of a timer, uses the 'number to text' to concatenate it with a rotation sensor output with a comma in between and then places it in a log file. It repeates this as often as possible. I found I needed to put a time stamp in, as Brian found, the processors tends to wander off every now and then to proccess some other info. Having the time stamp keeps the data valid even though the sampling rate is not perfectly consistant.
I ran the program on the TI-56 arm and manually opened and closed the gripper a few times.
Data file was then uploaded from the NXT and opened in Excel.
So what did I get?
I was pretty happy with the data. Sure there are sampling rate issues, but as a cheap datalogger I was very happy with it.
Closer inspection of the sampling rate showed just what is happening. With a quick Excel formula (sample time - old sample time) I could graph the time taken between each sample.
It's pretty consistant at 200Hz sampling rate with a regular blip about every 200ms where there is a gap of 11ms, and a more infrequent but larger gap of around 60ms about once a second.So is it usable? For a primary or middle schools implementation, I think it's great. Kids can learn about datalogging and get into the issues of "what do I log?" and "how often do I sample?" and still get vey useful data.
Stay tuned for part 2 where I have a go at sampling up to 4 sensors at once to see what the effect is. I'm also planning to dump the commas, and process the data in excel, a little more tedius but may give faster sample times.
--
Damien Kee
edit: Thanks Brian for explaining 'why' there are the delays
"1) The short spikes to 10 ms are when the FW writes the accumulated data to FLASH. It does not write every time a File Access block requests it, instead "saving up" data until a block of FLASH can be written at once (causing the delay).
2) The longer spikes are *probably* associated with copying the entire growing text file to a new place in memory. But I'm not yet sure.
3) Eliminating the commas doesn't really gain you much. Since each comma is a single character, but the data is generally 3 or 4 charecters (or more - numbers in text files are stored as, well, text), it reduces the amount that needs to be written... but not very much.
4) Ideally, you should make sure you are opening a "clean" file, and close it at the end of a session. Odd things can happen sometimes if you don't."