Thread Tools
Oct 20, 2015, 07:03 AM
Jack
jackerbes's Avatar
Thread OP
The code I am using is posted back in post #108 and it is this line that has the scale.set_scale value to make the displayed reading agree with the scale:

// this value is obtained by calibrating the scale with known weights; see the README for details
scale.set_scale(392.f);

I think I made a minor change to that value later and probably need to check it again to see if it needs to be adjusted for the difference between the pulling station I used before and the new one I made from the Servo City parts.

There is a video back there in post #116 showing how I used a LCD scale to calibrate the display on the Arduino display.

I would not say that it is an empirical measurement but it is certainly close enough for our purposes.

I have not used mine in some months but I am looking forward to upgrading it with your code! As always, there is no rush...

Jack
Sign up now
to remove ads between posts
Oct 21, 2015, 08:51 PM
Registered User
So just a quick update to my test bench. I've updated the throttle profile to pause every 25% (0, 25,50,75,100) of position for 5-10 seconds for a thrust reading. followed by a throttle ramp from 0-100-0. I've added a couple of LED's to signal the test is about to start and then while in test and then when the test is complete. Some code was added to also watch the IR temperature of the motor and if it exceeds 7.5 deg C more than the start temp it will abort the test to avoid smoking the motor. (two plots show that feature in action). I've included a rough schematic showing the layout of the bits I've used. I also decided to use interrupts and a FrSky BL motor sensor for the RPM measurements instead of the hall effect sensor. If I can re sort my plots to something logical in the next week of so I'll post some of the motor/prop data I've gathered.
Oct 22, 2015, 06:13 AM
Jack
jackerbes's Avatar
Thread OP
What is the application you are using to plot the data? And is that reading the data from CSV files?

Jack
Oct 22, 2015, 02:18 PM
Registered User
I'm using origin to plot the data.

I've attached a data file from a NTM 2826 1200 kv test using an 8x4 Multi Rotor prop. The file extension is .txt but the data is .csv and can be plotted in excel or other programs also.

(the zip file is the complete test, the .txt file is only 95 seconds of data)
Oct 22, 2015, 03:12 PM
Jack
jackerbes's Avatar
Thread OP
Origin, that does a nice job for sure.

I looked for some info on that Origin application but I got scared off by the price tag!

..Starting as low as $1095...

I saved your files and opened the 95s one with LibreOffice Calc and it seemed to organize and display all of the information nicely.

Between your project and Roger's (user maguro) plans I think I am going to have to get a lot smarter about using spreadsheets and plotting data from CSV files if I want to have any fun and advance my testing regimens very far.

Jack
Last edited by jackerbes; Oct 22, 2015 at 03:21 PM.
Oct 22, 2015, 04:03 PM
OpenTX University Staff
maguro's Avatar
I thought I post an update.

My initial plan was to use an Arduino 328P based board: a Nano or an Uno, but I quickly ran out of program storage, so I moved to Mega. I just got the SD card and SPort decoder functions working. The servo function for the ESC is a piece of cake. I will get it going on the Mega tonight.

I planned to go from zero to 100% thrust in 25% steps, then step down to zero. I thought about stopping for 5 seconds at each step (double that at 100 percent) and collect data at 1 second intervals. How does that sound?
Oct 22, 2015, 07:29 PM
Jack
jackerbes's Avatar
Thread OP
Interesting question. I think you might want more samples than that depending on how they display when graphed.

The eLogger capture rate can be set from as low as once every 5 minutes to as high as 50 samples per second. That rate is, of course, a factor in the smoothness of the curves in the lines as they are displayed in the Data Recorder application. As I use it, it collects data at the rate of 10 samples per second as that is the highest rate that can be displayed on the LCD power panel.

The line that has the most variation to it is the RPM but all of them have quite a bit of change as far as the values.

The first image is zoomed in on 32 seconds of time with a motor running at a constant 4500 RPM or so. Were it not for the high, low, and average values in the summary box below the image, that would really be a meaningless bit of graphing. I almost always use the average values from something like that and consider the averages to be an accurate statement of RPM.

The second image is 71 seconds of flight with a quadcopter (RPM taken from one motor of the four) and as you can see there is a lot going on there between my inputs and the flight controller's efforts at maintaining level and the like. You won't be flying your testing setup of course.

For static testing the graphed lines are smoother as you can see in the third image but still not smooth.

You can see more about how I use the plotted data and what I have to do to make it meaningful in this thread:

Using the Eagle Tree Systems eLogger - www.rcgroups.com/forums/showthread.php?t=2303109

So I'm not sure that once a second would be anywhere near often enough to give you very smooth lines on a real time display of the data.

I have thought about it before and I am not sure that I would get much use out of a display of all of the data streams on a real time basis as testing proceeded. I am really focusing on the values displayed on the Power Panel LCD display and as those values approach limits like the 120F max winding temperature or the 22A continuous/25A peak for my variable voltage DC power supply I am watching just that value.

I like knowing and having a list of the PWM rates, as displayed on my HJ servo tester throttle, and the values that equate to the 25/50/75/100 throttle percentages. I pause for about 5 seconds at each 25% more increment and and the same time am keeping an eye on the LCD power panel. And if one of the readings crowds a limit it gets more of my attention.

So for me, I think I will enjoy capturing all the data and being able to graph and capture the data streams after a static test but my focus will not be to watch the graphed lines as they are captured and developing on a monitor.

Jack
Oct 22, 2015, 09:06 PM
Registered User
To give you an idea on what roughly 1 Hz data looks like (this is 1 sample every ~.8 sec) i attached a couple of plots and a raw data file from some early tests if you want to mess around with it.

I was shooting for a rate of 1 - 10 Hz. for my data set (ended up closer to 10 Hz). Typically I'd suggest anything faster is just requiring more post processing (filtering/smoothing) for the information we are trying to get. Typically on aircraft flight data recorders the fastest rate has been for accelerations (typically 8 Hz), followed by flight controls.

I'm also of the opinion that you record the data in it's rawest form and save any filtering/smoothing for the post processing data part.

FWIW I've been using a 5V 16 Mhz Pro Mini for my setup and use about 53% for the program and 63% of the dynamic memory for my software....
Oct 23, 2015, 07:46 AM
OpenTX University Staff
maguro's Avatar
Quote:
Originally Posted by bizjet23
To give you an idea on what roughly 1 Hz data looks like (this is 1 sample every ~.8 sec) i attached a couple of plots and a raw data file from some early tests if you want to mess around with it.

I was shooting for a rate of 1 - 10 Hz. for my data set (ended up closer to 10 Hz). Typically I'd suggest anything faster is just requiring more post processing (filtering/smoothing) for the information we are trying to get. Typically on aircraft flight data recorders the fastest rate has been for accelerations (typically 8 Hz), followed by flight controls.

I'm also of the opinion that you record the data in it's rawest form and save any filtering/smoothing for the post processing data part.

FWIW I've been using a 5V 16 Mhz Pro Mini for my setup and use about 53% for the program and 63% of the dynamic memory for my software....
I'm using FrSky S.Port sensors and they have a minimum granularity of ~500 ms. Decoding the sensors consumes about 50% of the available memory. Add to that writing to an SD card, controlling the ESC, and the code for the thrust sensor, and a 328P just runs out of memory. I have a Mega, it's cheap, so why not? It's not like space is going to be an issue. If I decide to do something fancier with the thrust tester, I have all the ports, memory, and horse power I need.
Oct 31, 2015, 04:10 AM
Registered User
Quote:
Originally Posted by maguro
Decoding the sensors consumes about 50% of the available memory. Add to that writing to an SD card, controlling the ESC, and the code for the thrust sensor, and a 328P just runs out of memory.
Entire autopilots (Ardupilot/APM) run on a lowly 328p.

8 PWM inputs, GPS at 5-10 hz, 10 axis of IMU data, sensor fusion, waypoints, telemetry, 4-8 channels of PWM output, SD card logging, etc., etc..

Not trying to be a downer, but if you can't get 1/20th of that done... it's not the processor.
Oct 31, 2015, 08:49 AM
OpenTX University Staff
maguro's Avatar
Quote:
Originally Posted by jakestew
Entire autopilots (Ardupilot/APM) run on a lowly 328p.

8 PWM inputs, GPS at 5-10 hz, 10 axis of IMU data, sensor fusion, waypoints, telemetry, 4-8 channels of PWM output, SD card logging, etc., etc..

Not trying to be a downer, but if you can't get 1/20th of that done... it's not the processor.
I didn't say it was the processor, it's the available memory. Autopilots are written by people who have intimate knowledge of the electronics and are expert coders. They eek out every byte they can get.

I am have over 40 years in the computing business, but when it comes to Arduinos I'm just getting my feet wet. My code us very simple, but the necessary libraries eat up memory. Since I have a Mega and size is not a consideration, why not use it. I can get more space on the 328P by eliminating the boot loader, but why bother? I flat out don't need to use the 328P.
Oct 31, 2015, 09:19 AM
Jack
jackerbes's Avatar
Thread OP
Roger,

How are you controlling the throttle on you implementation?

I see the PWM rate displayed on my HJ servo tester and at first I considered using percentages of the theoretical throttle PWM rate range (1000-1500).

But in the end I decided to use percentages of the actual range of values that my Phoenix 80 ESC starts a motor at and then signals full throttle with an LED. That ended up to being something like 0% =984 and 100% = 1480. And I use percentage of that 984-1480 range.

It was probably not making a big difference but my P80 is very consistent on setting those values if I use the CC calibration routine when I power up the ESC and I liked that.

Jack
Oct 31, 2015, 10:47 AM
OpenTX University Staff
maguro's Avatar
Quote:
Originally Posted by jackerbes
Roger,

How are you controlling the throttle on you implementation?

I see the PWM rate displayed on my HJ servo tester and at first I considered using percentages of the theoretical throttle PWM rate range (1000-1500).

But in the end I decided to use percentages of the actual range of values that my Phoenix 80 ESC starts a motor at and then signals full throttle with an LED. That ended up to being something like 0% =984 and 100% = 1480. And I use percentage of that 984-1480 range.

It was probably not making a big difference but my P80 is very consistent on setting those values if I use the CC calibration routine when I power up the ESC and I liked that.

Jack
I'm using a simple servo setup, 0 to 180 degrees. I have a variable for the number of steps I want to take, and then increment the proper number of degrees for a step. I'm also adding an ESC calibration routine. It starts at full throw and drops to zero. That way any ESC I use will respond in the same way.

Currently I'm using a servo to simulate the ESC. Unfortunately under certain circumstances I get servo jitter while measurements are being taken. I also see spurious readings coming from the load cell. I calibrated it, and it is accurate to within a gram over a large range. The problem is that it could be indicating a couple hundred grams for a few readings then jump to a couple thousand, jump back to reading correctly, or possibly get a totally different spurious reading before reading correctly again. I'm averaging over 20 samples, but it makes no difference. Have you seen this behavior?

The FrSky S.Port telemetry scheme is timing critical, and I'm having issues there as well. If I sample from the main loop, readings settle down and look great, but embed the decoding in a couple of additional loops and I get mostly zero for the readings. If I can't sort this out, I'll have to use different sensors and start all over.
Oct 31, 2015, 01:56 PM
Jack
jackerbes's Avatar
Thread OP
No, I've never saw anything like that as I was testing and getting it working, nor have I seen anything like that in use since.

I wonder if it is reflecting a variation in the readings coming from the beam?

Do you have another beam you could try? Or HX711 board?

Jack
Oct 31, 2015, 09:06 PM
OpenTX University Staff
maguro's Avatar
Quote:
Originally Posted by jackerbes
No, I've never saw anything like that as I was testing and getting it working, nor have I seen anything like that in use since.

I wonder if it is reflecting a variation in the readings coming from the beam?

Do you have another beam you could try? Or HX711 board?

Jack
My guess is that it is the board. I'll get another an give it a try. Just out of curiosity, which HX711 library sre you using?


Quick Reply
Message:

Thread Tools