Alternative to Joly logic and Estes altimeters for less than 10 euros

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
So, I have a question to anyone who has taken a close look at the data from the gyroscopes on the QMI8658 on these boards. With my current setup, I'm getting spikes in the readings from time to time. They are not correlated with spikes in the accelerometer, so I don't think they are real. Also, they are only showing up on the X and Z axes - the Y axis is beautifully clean. Currently, I have the chip configured to read with a full-scale of 2048 degrees per second (~35.7 radians per second) and and output data rate of 470 Hz.

To take these readings, the board is fixed in an orientation (one is vertical, the other on one side) and 10000 readings are taken at the maximum rate that I can while storing all the data directly to a file (roughly 100Hz). As such, the data covers about a minute and a half. In both orientations the X and Z axes show the spikes while the Y axis does not. The temperature reading, and accelerometer readings are exactly what I would expect while the gyroscope readings would be were it not for the spikes.

I'm not actually sure that they will cause me any issue, it's mostly just interesting. If they are an issue, I can also test out increasing the data rate and enabling the low-pass filter on the chip.raw_gyros_1.png
On the plots, the y-axis scale is radians per second and the x-axis is in seconds. As can be seen in this dataset with the board vertical, the gyro X and Z channels show small spikes (certainly not saturating) with some frequency, but not often enough that it significantly impacts the reading if it's being filtered.
raw_gyros_2.png

By turning the board on its side, the Gyro X Axis does seem to change. The spikes are no longer bidirectional, and seem to be less frequent. Both the Y and Z axes are very similar however.

This isn't great for using the gyros to track the rocket's orientation, but it's rare enough that I don't expect it to be a huge problem.

Anyone else seeing this?
 
hello, so far I have not used much the accel and gyro data. I have recorded those only.
I am sure that you can filter those spikes using the Kalman filter. You will have to adjust the Q and R values until you find the correct ones
 
Meh, as previously mentioned, the temp sensor is pretty much useless once the device has been on for awhile. Reads like 46/47C which is like 117F, which I guarentee my house is not at.
Even on cold boot, its still reading about 10deg higher.
 
Meh, as previously mentioned, the temp sensor is pretty much useless once the device has been on for awhile. Reads like 46/47C which is like 117F, which I guarentee my house is not at.
Even on cold boot, its still reading about 10deg higher.
I guess it is due to the board eating up after a while. maybe record the intial temp when cold and substract after few minutes
 
Last edited:
hello, so far I have not used much the accel and gyro data. I have recorded those only.
I am sure that you can filter those spikes using the Kalman filter. You will have to adjust the Q and R values until you find the correct ones
I certainly intend to do some additionally filtering, but I just have an unhealthy compulsion to analyze the raw output of new sensors when I first start working with them....

I did find something interesting, however. The level of spikes (at least on my board) is proportional to the ODR that I configure for the IMU. If I set the ODR to 235Hz, I get a signal with no spikes at all. At 940Hz, I get what I showed. And at full tilt (7520 Hz), it looks like a porcupine. Enabling the low-pass filter certainly helps, but it doesn't entirely get rid of the spikes, like setting a lower sample rate does. So, at least for my setup where I can't sample much faster than 250Hz anyway, I'm going to stick to an ODR of 235Hz.
 
Meh, as previously mentioned, the temp sensor is pretty much useless once the device has been on for awhile. Reads like 46/47C which is like 117F, which I guarentee my house is not at.
Even on cold boot, its still reading about 10deg higher.
It's useless for tracking the air temperature, but I've compared the temp from the BMP280 and the QMI8658C, and they track each other extremely closely. It seems that they are providing an "accurate" reading of the die temperature. While that's basically useless for atmospheric recording, it could certainly be usable for temperature correction.

And yes. On cold boot, both temperatures are showing about 10C higher than room temperature and increase. Mine have only plateaued at around 36C, but I'm also running with Micropython, and on a single core. I'm not getting as much performance out of the processor as I could, so it's not likely to heat up quite as much.
 
I'll note that I tried switching libraries, and as part of that, I identified that its a BMP280 not a BME280 (reading the original advert its listed as BMP) so thats why humidity is 0. BME has a chipId of 0x60, and BMP has a chipIdof 0x58.
"BME280 can measure air pressure, temperature, and humidity, while else; BMP280 can only measure air pressure and temperatures."
 
Last edited:
It's useless for tracking the air temperature, but I've compared the temp from the BMP280 and the QMI8658C, and they track each other extremely closely. It seems that they are providing an "accurate" reading of the die temperature. While that's basically useless for atmospheric recording, it could certainly be usable for temperature correction.

And yes. On cold boot, both temperatures are showing about 10C higher than room temperature and increase. Mine have only plateaued at around 36C, but I'm also running with Micropython, and on a single core. I'm not getting as much performance out of the processor as I could, so it's not likely to heat up quite as much.
Well good to know its showing about 10C higher, but certainly not good for ambient temp. And since the temp is a constant, thats at
4.7C degrees, doesn't really give a good conversion from pressure to altitude especially when you consider flying in hotter temps (like at argonia or blackrock) around 32C.
 
Well think I have a BMP280 laying around from before I never did anything with, and BME280s boards on order, so going to try and separate out the sensor and see if it gets better readings.
 
hello all, I have just pushed to the Android store a new release of my console app. This will allows you to flash the altimeter with the lastest firmware.
https://play.google.com/store/apps/details?id=com.altimeter.bdureau.bearconsole
Note that flight recorded previously will no longer read as I have removed the humidity.
I have also fixed an issue which stop the recording due to the over pressure that happen at apogee due to the ejection charge when you attach the altimeter to your noise cone.

I still have some issues with the hibernate node which drains the battery within 2 days!!! so consider using a switch to power it on or off until I find a solution to that issue. Help would be appreciated if someone has any idea on how to fix it.
 
In the record altitude function I am stopping the recording a minimum of 2 seconds after apogee to prevent stoping recording when we get overpressured due to the ejection charge. Otherwise the rocket would think that it has landed. The logic was already implemented but buggy so I fixed it.
The bug was reported by a friend who flew it attached to the nose cone a week ago
 
In the record altitude function I am stopping the recording a minimum of 2 seconds after apogee to prevent stoping recording when we get overpressured due to the ejection charge. Otherwise the rocket would think that it has landed. The logic was already implemented but buggy so I fixed it.
I guess I don't see that change in the code... will have to try pulling down latest, since per github some of the files were deleted then reuploaded
 
Well good to know its showing about 10C higher, but certainly not good for ambient temp. And since the temp is a constant, thats at
4.7C degrees, doesn't really give a good conversion from pressure to altitude especially when you consider flying in hotter temps (like at argonia or blackrock) around 32C.
The 2.4 GHz WiFi communications being ON increases the operational temperature of the ESP32-S3. Placement of a heatsink on the ESP32-S3 without supplemental air flow did little to lower the temperature readings of the BMP280 and QMI8658 in my experiments. I did lower the temperature readings ~2°C with heatsinks on the BMP280 and QMI8658.
 
The 2.4 GHz WiFi communications being ON increases the operational temperature of the ESP32-S3. Placement of a heatsink on the ESP32-S3 without supplemental air flow did little to lower the temperature readings of the BMP280 and QMI8658 in my experiments. I did lower the temperature readings ~2°C with heatsinks on the BMP280 and QMI8658.
Would you want the WiFi on all the time eating power though? Certainly not while in flight.
 
I am not using wifi. I thought that it was off by default. Isn't that the case?
 
I am not using wifi. I thought that it was off by default. Isn't that the case?
I'm not sure it is off by default. It is an area that should be checked as a possibility for the elevated temperature readings. I was checking another ESP32-S3 module manufacturer, and they mentioned that the ESP32 operates at a higher temperature with the WiFi on. I can't check my ESP32-S3 TFT due to my uploading a configuration error, and it stopped all operations. I was searching for a configuration fix when I came across the WiFi issue.
 
Attached is the ESP32 Core Dump file I captured when I regained control of the ESP32-S3 TFT. I've looked up the Guru Meditation error and it is a BLERemote error. If anyone knows more, I would be interested in learning more.
 

Attachments

  • ESP32 ELF file SHA256 Dump.txt
    2 KB
Attached is the ESP32 Core Dump file I captured when I regained control of the ESP32-S3 TFT. I've looked up the Guru Meditation error and it is a BLERemote error. If anyone knows more, I would be interested in learning more.
I have had sketches in the past that would do that in particular with lots of serial.println. anyway uploading back a simple sketch after first going to boot mode always solved it.
 
Attached is the ESP32 Core Dump file I captured when I regained control of the ESP32-S3 TFT. I've looked up the Guru Meditation error and it is a BLERemote error. If anyone knows more, I would be interested in learning more.
/thread drift Some other system uses "Guru Meditation Error" besides AmigaDOS? That makes me smile. /thread drift
 
Finally got mine up and running, a little bit more to do although I've gone with WiFi and a web server for managing settings and data.
It's a cool little board and well worth messing around with.

Big thanks to bdureau for showing the boards as I've enjoyed experimenting with it.

This was just throwing it in the air, it seems to have detected my arm coming down to throw it and landing a bit lower than where I turned it on in my hand, so it seems fairly accurate at least. I was wondering if it could work for low altitude use as well as more conventional launches so allowed a 2m, 5m, 10m and 25m launch detect selection in the settings.

You set the local sea pressure forecast on my model so it can guess the launch site altitude and know what altitudes of air pressure you're passing through of course as well.

I think the strange apogee peak was because it was in a cardboard box spinning after throwing it, but we'll see what happens in a rocket soon.

1738180758963.png

1738182400112.png1738182433419.png1738182468239.png1738182498662.png

If anyone else gets stuck with sending files over 65KB via wifi without data corruption, it took me longer than it should to work out reading and sending the data one line at a time from the csv file. It's slower but works at least. There are probably better ways but it's my first play with some Arduino excitement.
Code:
void readFile2(fs::FS &fs, const char * path){
    server.setContentLength(CONTENT_LENGTH_UNKNOWN);
    server.send(200, "text/csv", "");
    File file = fs.open(path);
    while(file.available()){
      String line = file.readStringUntil('\n');
      server.sendContent((line));
      server.sendContent(("\n"));
    }
    file.close();
    server.sendContent(("")); // this final blank send is needed. 
    server.client().stop();
}
void handle_CSV_two() {
  readFile2(LittleFS, "/flight1.csv");
}

I've used the LittleFS to save and read the CSV files.
Takeaway points from that is to avoid the append option as it's very slow. Instead I've buffered the launch recordings into large arrays and write the whole data in one go at the end of the flight. To be realistic I've set a limit of 10,000 samples per flight at either 32 samples/sec for 5 mins max or 16 samples / sec for 10 mins max. I'll add an option which does 32/sec for the first 45 seconds before dropping to 15/sec as a compromise between the two though.
Writing a 400KB CSV this way takes about 1.5 seconds.
Code:
void writeCSV(fs::FS &fs, const char * path){
  File file = fs.open(path, FILE_WRITE);
  file.print("time_ms, altitude, acceleration_x, acceleration_y, acceleration_z, acceleration_overall\n"); // First line of the CSV titles.
  // Write the pre-recorded data from before launch detection. 
  for (int i = 0; i < buffer_alt_capacity -1; i++){
    temp_mo = sqrt(sq(buffer_accx[i]) + sq(buffer_accy[i]) + sq(buffer_accz[i]));
    buffer_alt[i] = buffer_alt[i] - recording_pressure;
    buffer_millis[i] = buffer_millis[i] - startMillis; 
    file.print(buffer_millis[i]);
    file.print(",");
    file.print(buffer_alt[i]);
    file.print(",");    
    file.print(buffer_accx[i]);
    file.print(",");    
    file.print(buffer_accy[i]);
    file.print(",");  
    file.print(buffer_accz[i]);
    file.print(",");    
    file.print(temp_mo);
    file.print("\n");
 }
 // End of pre-recording data now add the flight data. 
 for (int i = 0; i < recording_count -1; i++){
    temp_mo = sqrt(sq(buffer_accx[i]) + sq(buffer_accy[i]) + sq(buffer_accz[i]));
    buffer2_alt[i] = buffer2_alt[i] - recording_pressure;
    buffer2_millis[i] = buffer2_millis[i] - startMillis; 
    file.print(buffer2_millis[i]);
    file.print(",");
    file.print(buffer2_alt[i]);
    file.print(",");    
    file.print(buffer2_accx[i]);
    file.print(",");    
    file.print(buffer2_accy[i]);
    file.print(",");   
    file.print(buffer2_accz[i]);
    file.print(",");    
    file.print(temp_mo);
    file.print("\n");
  }
  file.close();
}
writeCSV(LittleFS, "/flight1.csv");
 
Excellent glad to see that other are also having fun. Are those 2 resistors for measureing the battery voltage?
 
Excellent glad to see that other are also having fun. Are those 2 resistors for measureing the battery voltage?
Yes, although I'd normally go for more than 33k's but they were handy (not many 1% resistors in the bits and pieces drawers).
Just went for halving on the resistors and it stores a 200 sample rolling average for the voltage which comes out pretty accurately.
I put some heat shrink on the leads which might not be visible in the pics as if both sides of the resistor touch the metal on the screen it sort of ruins the accuracy!
Code:
// Global
float voltage[201];
const size_t voltage_capacity = 200;

//Loop
  memmove(&voltage[0], &voltage[1], (voltage_capacity -1) * sizeof(voltage[0]));
  voltage[voltage_capacity - 1] = analogRead(A1);
Just have to sum and divide by voltage_capacity to get the average voltage when needed ofc. Although I probably didn't need a float now I re-look at it.
Also they are 1/8w as they fit tucked in on the board.
 
Last edited:
Back
Top