One of the things that has come up recently with regards to NXT-G v2.0 and datalogging is the speed that information can be logged. It seems the custom logging option under NXT-G v2.0 may be “slow”, in that it only logs somewhere between 10 and 100 readings every second (reports vary wildly, and until I test it myself I’m in no position to speak on this). Readers have pointed out, quite correctly, that NXT-G is not the fastest option for this. Robolab, for instance, is faster, and other offerings such as RobotC and pbLua are blazingly fast. But before everyone complains about this “new feature”, consider two other important points.
First is ease of use. It seems that with NXT-G v2.0, LEGO Education will be releasing a version that has a lot of the datalogging handled for the student (or the
teacher), making it easier to get and process data. That may require a slightly slower acquisition rate, but it may be more than worth it to some folks, especially if it provdes built-in smoothing, filtering, or averaging, as well as unit conversions etc. If you think this isn’t so, feel free to program in raw assembly language – the interface, the language, and the ease of use or familiarity of the environment makes a big difference on productivity, for people of any age. So “wrapping” datalogging in a nicer package, even if it’s slower, might be a very positive thing to many users. A very simple example (that could be greatly improved upon) is the "Easylog" program shown here.
Second is how fast you actually need to be. I had
some people skeptical that NXT-G could log at 100 samples a second, to which I replied it could, and it wasn’t hard. In fact it can do better than that. The first image is the graph of an incandescent lightbulb turning on and switching off, as seen by the light sensor of the NXT. My NXT-G program grabbed a sample every 4 milliseconds, or 250 samples each second, more than fast enough to resolve this phenomenon (even the very rapid 
cool-down when the light shuts off). But if I try this same trick using the Hitechnic acceleration sensor to measure the acceleration experienced while dropping the NXT on a party balloon, it doesn’t do as well – the datalog shows only about 1 sample every 20 ms, or just 50 samples each second, much poorer performance than for the previous example. Why? Is this due to the “slowness” of the NXT-G block, & should I switch to another language?
Well, no. In fact the “problem”, if you can call it that, is primarily I2C communications with the sensor – that’s the major slow-down. But even for simple analog sensors like the light or sound sensor, the NXT can only read them out every 3 ms or so, so that is the default rate in the firmware for those. You may try to “read” the sensor much faster, but if the underlying firmware and hardware isn’t able to respond any faster, you don’t get anything new. And in at least some cases, the issue is in the hardware itself: The old RCX sensors are supposed to get 3 ms of power before a read operation – they shouldn’t be polled faster than that. And the new NXT US sensor is subject to so many delays (not bad engineering, but limited to the “slowish” speed of sound), that while NXT-G lets you “read” this sensor in just 3.6 ms, the actual value only updates every 12 ms or slower (in some cases much slower). I2C communication, which is the negotiated exchange of bytes between the NXT & the sensors, is also slow – almost always slower than what the sensor is doing (if you are playing chess by mail, worrying about how long it takes to move a piece isn’t fruitful). So while you can complain that the NXT can’t read the acceleration sensor fast enough to integrate a position curve, I’m not sure it’s a valid complaint, given the cost of the system and the large number of other things it’s being asked to do (BT, PWM motors, drive and LCD and sound system, and do it all under complete control of a general-purpose user program, not something written especially for capturing data). And it’s doing it cheap, compared with a lot of other “datalogging” products out there.
Upshot: If the hardware can only produce a sensor reading every 3 to 4 ms, then being able to log them faster than that is very rarely an advantage... just a waste of memory.
I’ll finish up with one more fun example of the slow end of datalogging. With some sensors, there’s no
reason to worry about datalogging speed at all – the old temperature sensor (& likely the new one) is a very good example of this. Even when plunged from a hot to a cold environment, the sensor takes a significant amount of time to come into equilibrium with the new environment, so sampling it even 10 times a second is almost always much faster than needed. That’s not a fault of the NXT, NXT-G, or the sensor, but the physics of it (a mass takes time to change temperature, period). You can still have a lot of fun with this. For instance, I charted the temperature, sound, and light in my kitchen for more than 24 hours, at a time resolution of one minute, averaging the sound level during that interval & taking a “spot sample” of the light & temperature at the end of it. That was interesting enough I wanted to log two temperature
s (above a heater vent, & near the ceiling where the humid air from the shower goes) and the light & sound in my bathroom, but I wanted it to have a time resolution of 10 seconds… and I couldn’t let it run all night at that resolution (too much data). It took me about 1 minute to add some code that allows an arbitrary start time, and ta-da, the system started up right at 5 AM, capturing everything going on in our bathroom during that morning. Including the fact that I take a longer hotter shower than my wife, and that she got home at 5:30 AM after delivering a baby at the local hospital, and still had to get up and off to work about two hours later.
More datalogging examples have been tossed into my Brickshelf folder on the subject... but I'd love to hear from other users with other examples!
PS- It's also fun to try the old standby of monitoring your refridgerator temperature along with the light. Not only can you see that the light really does go out when you close the door, but you can see how often your refridgerator temperature various and by how much... not to mention how much the temperature goes up when the kids are standing there with the door open, trying to decide what to pack for lunch. Hey, you holding open that door! How many times do I have to tell you the temperature goes up almost 0.2 degrees per minute when you do that?!
--
Brian Davis
First is ease of use. It seems that with NXT-G v2.0, LEGO Education will be releasing a version that has a lot of the datalogging handled for the student (or the
teacher), making it easier to get and process data. That may require a slightly slower acquisition rate, but it may be more than worth it to some folks, especially if it provdes built-in smoothing, filtering, or averaging, as well as unit conversions etc. If you think this isn’t so, feel free to program in raw assembly language – the interface, the language, and the ease of use or familiarity of the environment makes a big difference on productivity, for people of any age. So “wrapping” datalogging in a nicer package, even if it’s slower, might be a very positive thing to many users. A very simple example (that could be greatly improved upon) is the "Easylog" program shown here.Second is how fast you actually need to be. I had
some people skeptical that NXT-G could log at 100 samples a second, to which I replied it could, and it wasn’t hard. In fact it can do better than that. The first image is the graph of an incandescent lightbulb turning on and switching off, as seen by the light sensor of the NXT. My NXT-G program grabbed a sample every 4 milliseconds, or 250 samples each second, more than fast enough to resolve this phenomenon (even the very rapid 
cool-down when the light shuts off). But if I try this same trick using the Hitechnic acceleration sensor to measure the acceleration experienced while dropping the NXT on a party balloon, it doesn’t do as well – the datalog shows only about 1 sample every 20 ms, or just 50 samples each second, much poorer performance than for the previous example. Why? Is this due to the “slowness” of the NXT-G block, & should I switch to another language?Well, no. In fact the “problem”, if you can call it that, is primarily I2C communications with the sensor – that’s the major slow-down. But even for simple analog sensors like the light or sound sensor, the NXT can only read them out every 3 ms or so, so that is the default rate in the firmware for those. You may try to “read” the sensor much faster, but if the underlying firmware and hardware isn’t able to respond any faster, you don’t get anything new. And in at least some cases, the issue is in the hardware itself: The old RCX sensors are supposed to get 3 ms of power before a read operation – they shouldn’t be polled faster than that. And the new NXT US sensor is subject to so many delays (not bad engineering, but limited to the “slowish” speed of sound), that while NXT-G lets you “read” this sensor in just 3.6 ms, the actual value only updates every 12 ms or slower (in some cases much slower). I2C communication, which is the negotiated exchange of bytes between the NXT & the sensors, is also slow – almost always slower than what the sensor is doing (if you are playing chess by mail, worrying about how long it takes to move a piece isn’t fruitful). So while you can complain that the NXT can’t read the acceleration sensor fast enough to integrate a position curve, I’m not sure it’s a valid complaint, given the cost of the system and the large number of other things it’s being asked to do (BT, PWM motors, drive and LCD and sound system, and do it all under complete control of a general-purpose user program, not something written especially for capturing data). And it’s doing it cheap, compared with a lot of other “datalogging” products out there.
Upshot: If the hardware can only produce a sensor reading every 3 to 4 ms, then being able to log them faster than that is very rarely an advantage... just a waste of memory.
I’ll finish up with one more fun example of the slow end of datalogging. With some sensors, there’s no
reason to worry about datalogging speed at all – the old temperature sensor (& likely the new one) is a very good example of this. Even when plunged from a hot to a cold environment, the sensor takes a significant amount of time to come into equilibrium with the new environment, so sampling it even 10 times a second is almost always much faster than needed. That’s not a fault of the NXT, NXT-G, or the sensor, but the physics of it (a mass takes time to change temperature, period). You can still have a lot of fun with this. For instance, I charted the temperature, sound, and light in my kitchen for more than 24 hours, at a time resolution of one minute, averaging the sound level during that interval & taking a “spot sample” of the light & temperature at the end of it. That was interesting enough I wanted to log two temperature
s (above a heater vent, & near the ceiling where the humid air from the shower goes) and the light & sound in my bathroom, but I wanted it to have a time resolution of 10 seconds… and I couldn’t let it run all night at that resolution (too much data). It took me about 1 minute to add some code that allows an arbitrary start time, and ta-da, the system started up right at 5 AM, capturing everything going on in our bathroom during that morning. Including the fact that I take a longer hotter shower than my wife, and that she got home at 5:30 AM after delivering a baby at the local hospital, and still had to get up and off to work about two hours later.More datalogging examples have been tossed into my Brickshelf folder on the subject... but I'd love to hear from other users with other examples!
PS- It's also fun to try the old standby of monitoring your refridgerator temperature along with the light. Not only can you see that the light really does go out when you close the door, but you can see how often your refridgerator temperature various and by how much... not to mention how much the temperature goes up when the kids are standing there with the door open, trying to decide what to pack for lunch. Hey, you holding open that door! How many times do I have to tell you the temperature goes up almost 0.2 degrees per minute when you do that?!
--
Brian Davis