Introducing the TinyTIM

[martinjaymckee]

I can agree with all the above except for #5. I even agree that avoiding pyro channels makes sense. While I worked in Java for my Computer Science degree, so far as possible, I avoid it like the plague these days. I didn't even like it now. Of course, I'm a great fan of C++, so I guess I'm in a different "camp." I see three approaches to the interface that I like.

1. Do it using a chrome browser application. The CleanFlight R/C auto-pilot works this way and is very slick. There are ways to interface to the file-system and serial port in a basically platform independent manner. All the rest of the code is entirely platform agnostic. This also gives a really nice distribution method, as it could go into the Chrome app store. Down side? well, it's web based ( I'm not a fan of web-based, in general ) and other than some quick searching through the CleanFlight code, I have no experience with Chrome Apps.

2. Program it in Python. Generally speaking, this is my favorite option. Like Java, Python is nicely cross platform. It has multiple library bindings for GUI including 3D graphics. Moreover, Pyserial is about the nicest cross-platform bindings for serial that I've seen, and they are still being developed ( unlike the Java RXTX bindings that Arduino uses... or used, I know there was talk of them going to different bindings ). It's a bit large, but Qt is an absolutely beautiful UI library and the Python bindings are a joy to work with. Python has the disadvantages that fewer people will have it installed by default, it's a bit more difficult to distribute ( nothing quite as nice as a JAR file ), and, I'll admit, perhaps a smaller programmer base.

3. As I've been thinking about this, I came up with another idea. Make the whole thing web-based, and wireless. Use an ESP8266 ( maybe an ESP-12E ) as the processor and just make the data available on a website hosted by the device. That would allow the system to be easily accessible as well as work on just about any device one could want to access the data with. There is an ESP8266 port of the Arduino IDE, so the code there could be, basically, standard Arduino code, and there would be no "PC" side code requirement ( if it were done correctly ). Just from the neato factor, I kind of like this idea. I have no idea how to make it work, however, as I haven't really worked with the required systems yet. Looks doable though, a quick grep of google shows several projects that use the broken out SPI bus on the 12E to talk to an SD card.

4. I admit it, there's some reasonable argument for a Java based interface. Worth keeping in the set of options.

The one feature request I would probably have for a DIY flight recorder would be a GPIO riser so that other boards could be mounted on the flight recorder. Maybe they would have extra sensors, perhaps pyro channels, maybe servo controllers or, whatever. Just pinning out the 3.3v power, I2C and four digital pins could be super useful in the future.

Martin Jay McKee

 

[Winston]

Lots of great ideas. However, what I was really aiming for in those specs was cheap and simple as possible using the best Chinese-sourced Ardunio sensor modules available right now which will get even cheaper (much cheaper) as they become older tech just as the older sensor tech modules are so cheap now. Then, using a quickly swapped microSD card while in still in the field being able to plug that card into the microSD card slot in any tablet, laptop, netbook, or smart phone that I own (they either have a microSD card slot or I don't buy them; I don't own any Apple hardware, only Android and Windows OS based hardware) and seeing all of the flight data, graphed data, and that animated 3D image although the last one would be more likely to be subjected to review and analysis in a home setting. A web based system would require a mobile data connection, not always available at launch sites. A low power wifi connection to a local device after recovery would be nice, but complexity and cost would go up as a result.

EDIT: Basically, the goal is a very data rich flight recorder that is so cheap and easy to DIY that it's as close as possible to the "Well, I lost it. No biggie, I'll just make another." That's the category my Estes Altimeters are in right now, but they are vastly less capable being altitude only. Using Chinese sourced modules would make flight hardware assembly just a very simple matter of soldering some header pins into a through-hole motherboard; no discrete components would be necessary.

 

[Winston]

Let me try to do a better job of explaining what I think would be a fantastic and UNIQUE open hardware and open source software project for hobby rocketry.

First, the goal should be to get as close as possible to disposable flight hardware. If I think there is a good chance that I might lose a rocket, I don't put my Altimeter II in it, I use an Estes Altimeter because it's much cheaper. However, I'd prefer far more flight data than just altitude.

Second, the hardware assembly process should be dirt simple. Modules soldered into a through-hole motherboard via headers would be easily doable by virtually anyone.

Third, the cheap Chinese sourced sensor modules allow the ultra low cost inclusion of every MEMS sensor type in production including one important for the 3D visualization close-up of the rocket in flight, a 3-axis gyro, useful for such things as the study of dynamic stability OR just to provide a "cool factor" in STEM. As far as I know, that gyro capability is only found in the most expensive commercially available flight hardware.

There are already all kinds of commercial products and hobby projects that are either very (too) simple or that include everything except the kitchen sink at major cost, especially if they are commercial products. Examples of some DIY projects:

https://hackaday.io/search?term=rocket

The more complex DIY ones like some of the ones at the link above get to the point where the cost and time invested in assembly remove them from the "disposable flight hardware" category.

What I'm suggesting is unique, I think, something that I've never seen anywhere as a DIY project or a commercial hardware kit - Chinese sourced MCU and sensor modules interconnected with a simple, through-hole motherboard with the MCU functioning only as a "dumb" raw sensor data recorder with launch detection. The microSD card where the flight data was stored is then inserted into a tablet, laptop, or PC where all of the data processing and data presentation is done.

 

[martinjaymckee]

I get where you're coming from. I don't believe, however, that "disposable" hardware has to preclude the possibility of a WiFi module -- specifically the ESP8266. A representative source from E-Bay would be something like this. That's five of the WiFi microcontrollers for about three dollars a piece. Easy enough to connect the Chinese modules or microSD to this, just like an Arduino. One of the nice things about the ESP-12E, is that it actually has holes on 2mm centers, so it can be mounted through-hole, in addition to surface mounted. In fact, a board could be designed for either. I would be more worried about the cost associated with losing a large microSD card than the ESP-12E.

The power argument is absolutely a valid one. There's no great way to deal with that when you have WiFi capabilities, except to turn them off.

Of course, even if the wifi capability wasn't used by one person ( it would work just fine to pull the memory card ), it could be useful for other people.

I guess my biggest concern is still in decreasing the cost of a high-rate accelerometer sensor board. I'd say that, otherwise, a GY-86 board provides everything. If the high-rate accelerometer is a separate board, though, it could be added only when desired, which would allow for decreased cost when it isn't needed.

I will say, I'm not really one that designs minimal systems well. I always find those opportunities to add functionality... and then I do. That said, the TinyTIM is one of my better attempts. If I hadn't added the pyro channels ( something of an afterthought really ) it would be pretty close to what we're talking about -- functionality wise. It is smaller, SMD and ( as a result ) more expensive though.

I find the "disposable electronics" an interesting idea all around. I keep thinking that I'm going to get some time to work on things... but not yet. I've got to get myself prepared for an L2 attempt on the 4th, so that will be much of my "free-time" for the coming week.

Martin Jay McKee

 

[Reinhard]

I guess my biggest concern is still in decreasing the cost of a high-rate accelerometer sensor board. I'd say that, otherwise, a GY-86 board provides everything. If the high-rate accelerometer is a separate board, though, it could be added only when desired, which would allow for decreased cost when it isn't needed.

If you feel confident with a bit of SMD rework, you can get a cheap ADXL345 board and replace the sensor with an ADXL375. The result wont be as cheap as other sensors, but it is probably the lowest price one can get in prototype quantities.

Reinhard

 

[Winston]

I get where you're coming from. I don't believe, however, that "disposable" hardware has to preclude the possibility of a WiFi module -- specifically the ESP8266. A representative source from E-Bay would be something like this. That's five of the WiFi microcontrollers for about three dollars a piece. Easy enough to connect the Chinese modules or microSD to this, just like an Arduino. One of the nice things about the ESP-12E, is that it actually has holes on 2mm centers, so it can be mounted through-hole, in addition to surface mounted. In fact, a board could be designed for either. I would be more worried about the cost associated with losing a large microSD card than the ESP-12E.

I don't know why I thought they were more expensive than that. Haven't been paying enough attention I guess. That is cheap.

I guess my biggest concern is still in decreasing the cost of a high-rate accelerometer sensor board. I'd say that, otherwise, a GY-86 board provides everything. If the high-rate accelerometer is a separate board, though, it could be added only when desired, which would allow for decreased cost when it isn't needed.

The cheapest high-g accelerometer for quantity purchases I've been able to find is the very recent tech, extremely low power 3-axis 100g H3LIS100DL. Only 8-bit data output, though:

https://www.st.com/content/ccc/reso...df/jcr:content/translations/en.DM00162193.pdf

$5.46 in unit quantities.

I find the "disposable electronics" an interesting idea all around. I keep thinking that I'm going to get some time to work on things... but not yet. I've got to get myself prepared for an L2 attempt on the 4th, so that will be much of my "free-time" for the coming week.

Martin Jay McKee

Check out this project that I just found:

Model Rocket Data Logger
A small accelerometer, thermometer, altimeter, SD card logger, with a radio downlink.

https://hackaday.io/project/7189-model-rocket-data-logger

Everything except the high-g accelerometer, gyro, and the motherboard concept which I think is an essential part of the idea. I also has s radio beacon.

 

[Winston]

If you feel confident with a bit of SMD rework, you can get a cheap ADXL345 board and replace the sensor with an ADXL375. The result wont be as cheap as other sensors, but it is probably the lowest price one can get in prototype quantities.

Reinhard

I'm thinking about designing and having commercially made a small number of 3-axis 100g chip H3LIS100DL-based modules IF everyone thinks 8-bit data would be adequate, otherwise it would use a very close to twice as expensive chip, the H3LIS331DL which is 16-bits. I don't need the money nor the hassles, so I'd just make it available to anyone here, not on eBay or Tindie. There are already two H3LIS331DL modules on Tindie, but they aren't cheap because the persons selling them want to be compensated for their time and effort:

https://www.tindie.com/search/#q=H3LIS331DL

 

[Reinhard]

I'm thinking about designing and having commercially made a small number of 3-axis 100g chip H3LIS100DL-based modules IF everyone thinks 8-bit data would be adequate, otherwise it would use a very close to twice as expensive chip, the H3LIS331DL which is 16-bits[/url]

The resolution of the H3LIS331DL is 12bits, only the readout is 16bits. The ADXL375 is similar (13bit resolution, 16bit readout).

Reinhard

 

[Winston]

The resolution of the H3LIS331DL is 12bits, only the readout is 16bits. The ADXL375 is similar (13bit resolution, 16bit readout).

Reinhard

H3LIS100DL - 780 mg/digit
H3LIS331DL - 49 mg/digit (@100g setting)

Anyone know if the .78g resolution due to the 8-bit data of the H3LIS100DL is adequate? The single axis, 12-bit 105g MMA6555KW is virtually the same price as the H3LIS100DL, but it's an older part that's not as power efficient and is not nearly as widely available as the H3L devices.

https://octopart.com/search?q=MMA6555

https://octopart.com/search?q=H3LIS100DL

https://octopart.com/search?q=H3LIS331DL

The highest acceleration of anything I've simmed is a 29mm minimum diameter supersonic design whose maximum acceleration is 50g.

 

[UhClem]

Anyone know if the .78g resolution due to the 8-bit data of the H3LIS100DL is adequate?

Adequate for what?

 

[martinjaymckee]

I have to agree with UhClem. The H3LIS100DL's .78g resolution is perfectly adequate -- if your application requires a resolution of 1g. The question is, what is the high-rate accelerometer going to be used for? I have two uses, myself. The first is at liftoff ( predictably ). I usually plan to have at least 8-bit resolution in my "standard" sensor range. At that rate, I'd have to use the whole 100g range, and that's unlikely ( in the extreme ) to happen at liftoff. Most of the flights that I have been simulating recently have a maximum acceleration in the range of 25gees. As such, the H3LIS100DL would give around 32 counts, or 5-bits. That's rather low. The other application for the high-rate accelerometer I see is for recording the severity of ejection charge reactions. Several issues back in Sport Rocketry there were a series of articles on a data acquisition system for ARLISS launches. One of the things that I found fascinating was the sharp, high-acceleration, signals at recovery events. Those would almost certainly saturate the H3LIS100DL and use the whole 8-bits. At that point, I think it'd be carrying its own weight quite nicely.

I guess that my thought is that 8-bits is sufficient if the whole purpose of of the high-rate accelerometer is to give a rough outline of the flight. After all, more readily available 16g accelerometers should cover the bulk of the flight with quite fine resolution ( and then we get to considerations of noise... ). Using two accelerometers with different range capabilities is pretty handy here though.

@Reinhard
I know I'm not comfortable enough with SMD rework to remove a QFN and replace it on a populated board. I did design an ADXL3xx breakout board though. It only cost me ~$2.50 for three boards from OSHPark, and I can mount and ADXL345 or ADXL375 on it. Works quite nicely, actually. Obviously that wouldn't be as compact as using a commercial board and reworking it, but it needn't be much more expensive than simply buying the accelerometer.

@Winston
I am certainly interested in a board if you come up with one before I have a chance to do so. I ended up with a construction project, so I'm not going to have tons of time the beginning of this summer, but I want to keep pressing ahead on rocket electronics, if only to save what small amount of sanity I still retain.

Cheers all!

Martin Jay McKee

 

[Winston]

I have to agree with UhClem. The H3LIS100DL's .78g resolution is perfectly adequate -- if your application requires a resolution of 1g. The question is, what is the high-rate accelerometer going to be used for? I have two uses, myself. The first is at liftoff ( predictably ). I usually plan to have at least 8-bit resolution in my "standard" sensor range. At that rate, I'd have to use the whole 100g range, and that's unlikely ( in the extreme ) to happen at liftoff. Most of the flights that I have been simulating recently have a maximum acceleration in the range of 25gees. As such, the H3LIS100DL would give around 32 counts, or 5-bits. That's rather low. The other application for the high-rate accelerometer I see is for recording the severity of ejection charge reactions. Several issues back in Sport Rocketry there were a series of articles on a data acquisition system for ARLISS launches. One of the things that I found fascinating was the sharp, high-acceleration, signals at recovery events. Those would almost certainly saturate the H3LIS100DL and use the whole 8-bits. At that point, I think it'd be carrying its own weight quite nicely.

I guess that my thought is that 8-bits is sufficient if the whole purpose of of the high-rate accelerometer is to give a rough outline of the flight. After all, more readily available 16g accelerometers should cover the bulk of the flight with quite fine resolution ( and then we get to considerations of noise... ). Using two accelerometers with different range capabilities is pretty handy here though.

That's exactly the sort of answer I was looking for. I haven't found a decent description on-line about what sensor is being used for what purposes in a rocket IMU. Some are obvious, like the barometric sensor being used for altitude determination, but is the accelerometer output also useful in backchecking that figure since it can be used to calculate distance traveled and, therefore, altitude. If so, what resolution would be needed for that? These are the sort of stupid questions I ask when I don't have a complete theory of operation for rocket IMUs.

I was thinking the same on the 16g accelerometer already present in the multi-sensor chip in the base system being most useful in most cases. I'll need to go through my many Rocksim and OpenRocket files to see what kind of accelerations are experienced by a representative sample of flights.

I am certainly interested in a board if you come up with one before I have a chance to do so. I ended up with a construction project, so I'm not going to have tons of time the beginning of this summer, but I want to keep pressing ahead on rocket electronics, if only to save what small amount of sanity I still retain.

Cheers all!

Martin Jay McKee

The H3LIS100DL (3-axis 100g 8-bit) and the nearly twice as expensive H3LIS331DL (3-axis 100,200,400g 12-bit) have exactly the same pinout, so the same PCB could be used for both. Since the GY-86 already has on-board pull-ups as do other IMU modules I suspect, while there should be pull-ups available on the H3LISxxx module's I2C lines just to make it more general purpose, they should come disabled to be enabled by the user if desired by a single solder-bridge jumper. I think I'll make the module I2C only as did this seller:

https://www.tindie.com/products/onehorse/h3lis331d-hi-g-accelerometer/?pt=full_prod_search

No timeline projections as I have multiple ongoing projects in various hobbies.

 

[UhClem]

I have started to get a little data at 8,000SPS from a MPU-9250 and the difference between the DLPF settings of 250Hz and 3600Hz is pretty obvious.

 

[martinjaymckee]

Wow, you're not kidding. There is quite a difference in the noise. Then again, that is only to be expected. Basic root-mean-squares noise -- proportional to the square-root of bandwidth -- would predict noise on the order of four times as large for the 3600Hz case ( over 250Hz ). It looks to me that it's pretty close to that ( a bit under 1d/s rms to a bit under 4 d/s rms ). Still, that's quite impressive, even at 3600Hz.

My plan for the TinyTIM ( and later versions with GPS ) is to run a Kalman filter. In a nutshell, a Kalman filter does two steps -- prediction and correction. In the prediction step, the filter estimates the "state" of the rocket based on a physical model. The correction step takes readings ( from the sensors ), and adjusts the estimate based on those known readings. The most important things that the Kalman filter does, however, is to "optimally" make these adjustments based on how "good" the model or sensor seems to be. Basically, give a set of constraints, it makes the absolute best use of the model and the measurements possible. Now, there are some major limitations in those constraints, but, it can make quite a difference. It can also combine multiple sensors.

For instance, in the TinyTIM, the system state consists of vertical position ( altitude ), vertical velocity, and vertical acceleration. Note, because of the included gyroscopes, it is possible to rotate the accelerometer reading back into a standard reference frame and minimize errors that come from non-vertical flight. The Kalman filter estimates these three state variables using a simple newtonian model. It corrects using three values: 1) barometric altitude, 2) low-rate accelerometer and 3) high-rate accelerometer. Now, each of the state variables can be estimated from the sensor readings - e.g. vertical velocity can be estimated as either the integral of acceleration of the derivative of altitude. This is precisely what the Kalman filter does. But, it also checks how close the model and the sensors actually match. If a sensor fails to match, the kalman filter gives it less weight. The way I intend to use this is that I can get high resolution readings of acceleration with the 16g accelerometer in the MPU6050 ( that I have on the GY-86 ) and lower resolution readings from the ADXL375 ( as it has a full-scale range of 200gees ). When acceleration is greater than 16gees ( a small portion of the flight, really ) the sensor will saturate, the filter will find that it doesn't match the model and the other sensors, and it will throw-out that sensor. Once acceleration is back in range, the filter will begin to use the data again. The reason I mention all of this goes back to the question of how much resolution is necessary.

I am happy to have the 13-bit resolution available for the high-rate accelerometer on the TinyTIM, but, I have little doubt that it would work just as well with an 8-bit accelerometer precisely because at lower accelerations ( where the rocket will spend much of its time ), there are sensors that have much better effective resolution ( the MS5611 is 24-bit resolution and has an altitude resolution down to 10cm ). All of this can be taken advantage of in the DIY altimeter. If the data is stored raw, the viewing/downloading application can do the kalman filtering at that point. Even if the processor is unable to do the filtering in "real-time" on the altimeter, downloading it to a PC to process allows for many algorithms to make optimal use of the available data.

So. For what my two-cents are worth ( two-cents, I guess... ) I'd say that a good first design would be based on the H3LIS100DL and another, inexpensive, low-range accelerometer. Limiting sampling rate to something less than 500Hz, it should be perfectly do-able to interface with just I2C. What keeps popping into my head, however, is a motherboard with a standardized connector that sensor cards could be inserted into. There could be two of the connectors, one on either side, with I2C, power, and a couple of GPIO pins. I don't know, probably not worth the trouble to design.


@Winston
If you get a breakout board done first, or I do, or someone else entirely, it doesn't really matter. We'll get there in the end.

Martin Jay McKee

 

[Reinhard]

What keeps popping into my head, however, is a motherboard with a standardized connector that sensor cards could be inserted into. There could be two of the connectors, one on either side, with I2C, power, and a couple of GPIO pins. I don't know, probably not worth the trouble to design.

How about PMOD? This is about the closest thing to a standard that I can think of on this level.

Reinhard

 

[martinjaymckee]

Yes, PMOD would be a good option -- that is actually where I got the idea ( through a few iterations in other projects ). The primary "issue" I have with PMOD is keeping the total package size down. It would be easy enough to flush-mount a PMOD board on one side ( if the motherboard is single-side load ) but through-hole components may still hit. PMOD on both sides would be even more of an problem. Still, worth thinking about.

Martin Jay McKee

 

[Winston]

So. For what my two-cents are worth ( two-cents, I guess... ) I'd say that a good first design would be based on the H3LIS100DL and another, inexpensive, low-range accelerometer. Limiting sampling rate to something less than 500Hz, it should be perfectly do-able to interface with just I2C. What keeps popping into my head, however, is a motherboard with a standardized connector that sensor cards could be inserted into. There could be two of the connectors, one on either side, with I2C, power, and a couple of GPIO pins. I don't know, probably not worth the trouble to design.

@Winston
If you get a breakout board done first, or I do, or someone else entirely, it doesn't really matter. We'll get there in the end.

Martin Jay McKee

Thanks for the IMU explanation. Looks like the H3LIS100DL will be sufficient.

 

[martinjaymckee]

I hadn't thought about it piggybacking off the GY-86, I like the idea. Even if the GY-86 disappears, it wouldn't be any worse than any other pinout for a breakout board.

Martin Jay McKee

 

[Winston]

First of all, this is not intended to be an attack on any of the various rocket instrumentation projects people have been kind enough to share with the community. Your project and goals are YOUR project and goals. Many who do such projects are highly praiseworthy autodidacts who do them more as a self-educational effort and challange than anything else. However (there it is), today I've just seen the umpteenth example of what I'll call YAOSHPTVNOWEB (Yet Another Open Source Hardware Project That Virtually No One Will Ever Build) and I want to again make some points about why this is so.

With many open hardware electronics projects, one has no choice but to use complex PCBs using surface mount components especially these days when so many of the most interesting and useful components are available only in surface mount packages. However, due to the ready availability of CHEAP Chinese sensor and MCU modules, most of them costing much less than what the low order quantity cost of the individual components would add up to let alone the cost of the multi-layer PCB, that doesn't need to be the case with rocket instrumentation. A relatively simple 2 sided through-hole motherboard into which those various low cost Chinese sensor modules and a low cost MCU module can be soldered and thereby simply and solidly interconnected by virtually anyone remotely familiar with a soldering iron is the way to go to achieve an open hardware/software project that a significant number of people will actually build.

Here's the latest example of an impressive YAOSHPTVNOWEB:

OpenTelemetry - Affordable, easy to use and open source Telemetry System for model rockets

https://hackaday.io/project/12203-opentelemetry

That project has many good points (SD card data logging, GPS, telemetry), a few defects (no gyro sensor, my main desire in an inexpensive IMU, and an accelerometer that handles a max 16g), but the same capabilities could have been achieved using a possibly larger PCB with Chinese sensor and MCU modules. If it had been, even with its defects, I'd have probably built one. As it is, it's not nearly as likely that I will.