Thread Tools
Jan 12, 2013, 10:45 PM
Registered User

G sensor not reading correctly

I just unpacked and connected my V4 and Low G sensor. Running V 10.04 software and firmware has been updated. When I check the sensor values in live mode wrt gravity they do not read correctly.

Zaxis = .89g
sensor on side Xaxis = -.96 +.93
Sensor on end Yaxis = -1.0 to .99

So only the yaxis seems to be reading correctly. Anyone run into this or have a solution?
Sign up now
to remove ads between posts
Jan 14, 2013, 09:20 PM
billpa's Avatar
Hi Bob,

sorry about the G sensor issue. 0.95 is around the margin error of the sensor, but 0.89 is not.

when you say you updated the firmware, did you update the gForce firmware also, or just the eLogger firmware? And, can you let me know when you purchased the sensor?
Jan 19, 2013, 10:39 PM
Registered User
I just received the system about two weeks ago.

The first time I plugged the unit in it did a firmware update and there was a gforce expander calibration that popped up as well. I didn't do anything with the g force calibration as I was told the unit was factory calibrated and it was not possible to calibrate it anyway.

I also opened a support ticket and received a response Friday suggesting I return it to be recalibrated. I won't be doing that as it will be faster and cheaper to buy a new unit if I decide to worry about the accuracy of the z axis.

I am also having problems with both the brushless motor RPM sensor and the optical sensor. The Brushless RPM sensor gets huge spikes when the motor is running. This is a car application so there is a lot of RPM change. Peak RPM on the motor should be 14 kRPM and I get spikes to 50-60 kRPM when throttle changes. Hard to make sense of the data with all the spikes.

After that experience I figured I'd just use the optical sensor I bought as well. I can't get it to read properly at all. I roughed up the black plastic surface of a drive cup to remove the shine and painted 1/2 of it white. It's about 10mm diameter. I get an output but the RPM and speed calculation is wrong. It doesn't matter where I say the sensor is located, motor, spur gear or axle the output RPM and speed in live or logged mode never changes. The gear box ratio is 2.5:1 with a 75T spur and 48T pinion. The motor RPM should read around 13.5kRPM but it always reads 5.4kRPM. And I mean always. Even when I change the gearbox ratio to 1 and the pinion/spur to 1 it reads the same. I could understand if that was the drive shaft RPM but it isn't. Drive shaft RPM at full throttle is around 9kRPM.

Yours truly very frustrated.
Last edited by BobW99; Jan 19, 2013 at 10:41 PM. Reason: typo
Jan 21, 2013, 10:36 AM
Registered User
Was at the track yesterday to do some testing and discovered another issue.

When you save a .cdr file for some reason none of the g sensor data is saved to the file. I know it was recorded because I checked when I downloaded it to make sure everything I wanted was recorded. Xaxis and Yaxis was there but couldn't graph Zaxis because there is not option to graph it.

When I got home and opened the file to do some analysis there was no g sensor data at all. I looked at the .cdr file in excel and there isn't even a column for the data to be saved in. The only data saved was pack voltage, current and RPM.

Not sure what is going on now.
Jan 21, 2013, 08:37 PM
billpa's Avatar
BobW99, sorry for the issues you are having!

First, regarding the spikes with the brushless, you should be able to eliminate those by clicking "Advanced, Set Min Max Values" and set the max value below the spike values you are seeing, but above the max valid reading. Then, when you download data from the logger again, there should be no spikes.

Regarding the optical motor issue, I want to confirm that you downloaded the recorder data again, after making the changes to the RPM parameters? That is necessary for the data to be affected by the settings changes.

Also, we have made some improvements to our software support of the car profile with the eLogger, so I would recommend downloading beta version 10.43 of our software, located here. Please let me know if I can help further!
Jan 23, 2013, 09:11 PM
Registered User
Thanks for the reply Bill.

OK I downloaded the Beta 10.43 and updated the V4 and g sensor firmware.

The Zaxis value is now reading .92 g now which is better. Would the g sensor firmware update have something to do with that or is it just sensor drift?

I tried the min/max RPM limiting and it works well in bench testing. Hopefully it will work well on track where the current draws are much higher. On track is where I have been having the problems. The RPM reported in Live model is 13500 RPM which is correct for the motor I am using.

When a log file is saved and then reloaded the g readings are still not there. The program doesn’t seem to be writing them to the .cdr file.

In one of the next updates I would like to see the Zaxis values available for display as well. Currently Zaxis cannot be selected in graphing module.

The optical sensor is still not reading correctly. Also the only way I can get the Speed calibration to accept new values is to close the program and restart it. If I make a change to the speed calibration parameters and just download the data from the recorder again the RPM and speed data is unchanged. Also the sample rate used to convert RPM to speed is different that the recorder data rate. I am using 50 hz sample rate and the graphed speed data looks like it is converted at 10 hz or less. I can send you a screen capture if you like.

To try and figure out what is going on with the optical sensor I downloaded the same data file from the recorder while changing the sensor position. The sensor is actually mounted on the drive shaft which rotates at spur gear speed.

The values used on the calibration sheet are as follows Spur = 75, Pinion = 46, Gearbox = 2.5, Tire dia = 2.48 in. The motor Kv=1850 and battery voltage = 7.5V. (approx motor RPM = 7.5x1800 = 13875 RPM)

First test - Sensor on pinion/motor Reported Motor RPM = 8447
Since no correction should be applied to the RPM this should be the actual RPM of the drive shaft where the sensor is mounted. The drive shaft speed should be around 13875 * 46/75 = 8510 RPM so the reported value looks good. Assuming this number is correct the second test was to change the sensor position on the calibration sheet to the actual sensor position on the spur.

Second Test - Sensor on Spur Reported Motor RPM = 5181
Using the 8447 RPM from the first test as the shaft speed the Motor RPM would be 8447 *75/46 = 13772 RPM. It appears the program uses 8447 * 46/75 =5181. So the pinion/spur ratio is inverted from what it should be.

Last question. I have an old hall effect sensor from a CDR V1 I bought 10 years ago. Will it work with the V4 logger? This method used to work fine so I think I will try it if the optical sensor won’t work.

Hope this makes sense.
Jan 26, 2013, 04:44 PM
billpa's Avatar
Hi, and glad to hear that the RPM spike and Z axis issues may be resolved. Once the firmware update was made to the accelerometer, there should not have been further changes to the Z axis. But, any data logged before the change would not have been affected.

Regarding the Z axis display in the logs, I think the issue may only occur with the elogger in car profile. I have reported this issue to our software developer to fix. In the interim, if you switch to the flight profile (under Software, Choose Model Type), I believe this will resolve it (though this is definitely not user friendly I realize)!

Regarding the reversal of the pinion/spur ratio, that's interesting. That work was done around 10 years ago (for the CDR V1) in concert with a noted RC car racer. It's possible he had it backwards mentally, but we haven't had other reports about that, and it's probably too late to change it at this point (it would change the behavior for those expecting it to remain the way it is).

To the best of my ability to recollect, the original RPM sensor should work fine.
Jan 26, 2013, 07:46 PM
Registered User
Bill, I think you may have missed one of my main points.

When you download a logged file that contains X and Y axis G sensor data and view it in the 2D graph mode everything is fine. The X and Y G sensor data is there. Now save that file to disc and then reload it. THE G DATA IS NOT THERE!!!. It seems the program does not write it to the file.

As far as using the flight mode to log Zaxis data is concerned that won't do me much good when. I need ground speed too, so this is not a solution I can use.

I will try to change back to the Hall effect sensor but in the interim maybe someone at Eagletree should try the optical sensor in "CAR" mode and see if you can replicate my problem. I'm not an idiot. This is a real issue and the amount of time I have wasted trying to resolve it is idiotic.
Jan 28, 2013, 08:50 PM
billpa's Avatar
Hi, we have been able to reproduce the issue you reported with the Z axis of the G-sensor data not being written to the log file or visible in the graph, when the eLogger is used with the car profile. This has been fixed, and is in test now. We should have a new version this week.

We are investigating the issue where you have to restart the software after changing the gearing parameters to have them take effect. That should not be happening.

Regarding the issue with the optical sensor, unless I am misunderstanding, you are seeing data that appear to be correct if you swap the pinion and spur gear settings? All the sensors use the same algorithm for RPM calculation, I believe, so I'm confused about that.
Jan 29, 2013, 09:18 AM
Registered User
I wrote this before seeing your post. It explains everything.

OK I have done a bunch more testing and figured out the problems. If I am wrong on this I will surrender my engineering degree to Eagletree.

All tests were run using a 2 pole, 2100 Kv motor running at 7.5V. Expected peak RPM = 15,750

First the Brushess RPM Sensor
I have compared brushless RPM measurement between Flight and Ground mode and get different measurements between modes. I suspect there is an issue with the post processing of the signal in car mode since changing the number of motor poles in car mode has absolutely no effect on the output RPM. In flight mode changing the number of motor poles has the expected effect.

Flight Mode Motor RPM = 16,200 RPM
Car Mode Motor RPM = 13,200 RPM

Now for the Optical and Hall effect sensors. There are two issues here. First the Number of magnets or light strips entered in while in Car Mode has absolutely no effect on the RPM calculation. This is the same issue noted above for entering the number of poles for the Brushless sensor. Both sensors work perfect for the values entered in Flight mode. The good news is if you are using two magnets with the Hall Effect the measured RPM is correct. For the optical sensor the RPM will be ˝ of the actual.

The next issue is two of the radio buttons for selecting the location of the optical or hall effect sensor are reversed. If your sensor is located on the spur then select the radio button for sensor mounted on motor/pinion. If your sensor is mounted on the motor/pinion then select the spur. This will produce correct RPM and speed readings. If you sensor is mounted on the axle then selecting the Axle radio button will be produce correct readings.

I installed my old hall effect sensor with two magnets mounted on the spur and I get correct readings using the above procedure.
Motor RPM = 16,200 RPM
Speed = 47 kph

Saving g sensor readings does not work in car mode. It works fine in flight mode. It would be nice to be able to look at Zaxis readings in Car Mode since the data is already there.

That’s all for me. I can fudge the output to get correct readings now. Hope this helps someone else.
Jan 30, 2013, 04:12 PM
billpa's Avatar
Hi Bob,

Thanks for this report - we're investigating what is going on here. I agree that the issue is most likely a problem with using the RPM settings with the eLogger in car mode. We'll get these addressed.

The issue of Gforce with the eLogger in car mode is now fixed. That fix will be available after further testing here.
Jan 31, 2013, 10:12 AM
Registered User
Great that the GSensor readings will now be saved to the .cdr file. Let me know when the update is available so I can restart my testing.

Just to clarify the issue with the sampling rate in the RPM - Speed conversion I have attached a screen capture.
Feb 03, 2013, 05:54 PM
Registered User
I looked at the RPM to speed data and it seems the problem is the speed is being converted to an integer value. So you start with a number that has 5 significant digits and convert it to a number that has two. Just change the formating of the speed number and the staircase effect will be gone.
Feb 04, 2013, 06:20 PM
billpa's Avatar
HI Bob,

Thanks for the additional information. Yes, that's correct - speed is treated as an integer in our software. In most cases the additional resolution would not be meaningful. It's something that's fairly deeply embedded in the software and the file format, but if we get requests to change it, we can.

The change for gforce/eLogger/car mode has been posted here. Note that this is "alpha" software that has had very little testing!
Feb 07, 2013, 07:36 PM
Registered User
Just installed the alpha software. X, Y and Z axis data is now in the .cdr file. Thanks for fixing that.

No changes to the ground speed calibration problems though. Is that coming in the next version?

You can put me down as requesting at least one decimal point in the RPM to speed conversion format.

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Suggestion Mark Forum Read - dones not change fonts correctly helicow Site Suggestions / Complaints 2 Oct 17, 2012 01:06 PM
Discussion How To Correct A Bad Habit - I'm not Not Using Rudder Control itsme2 Beginner Training Area (Aircraft-Electric) 22 Sep 30, 2012 01:26 PM
Discussion To SENSOR or NOT to Sensor... That is the question. Kev71H Motorcycles 14 Jul 04, 2012 10:56 AM
Discussion Voltage sensor not reading correctly on ER9x w/FrSky razorseal Radios 6 Apr 14, 2012 11:41 AM
Help! Logger not reading correctly? beans07 Eagle Tree Systems 1 Apr 24, 2010 05:37 PM