OSHW Bluetooth telemetry board discussion & spec-out

[Gip-Gip]

Hello!

I've been tinkering around with the idea of a Bluetooth rocket telemetry board. So far I only have a Bluetooth attiny test board as a proof of concept, but before I go on to make the first real prototype I need some goals to aim for

Current specs:

• Operating voltage between 2.7-3.6v
• Maximum measurable acceleration of 16g
• BTLE support
• 1 accelerometer and 1 axial accelerometer
• 1khz sample rate, with some sort of variable averaging algorithm to reduce memory usage while preserving velocity accuracy(I suck at explaining things sorry if that doesn't make sense)
• 128kb non-volatile memory, preferably Fe-RAM
• In-circuit programmable MCU
• RN4871 Bluetooth/I2C interface

Possible extras:

• Buzzer that can be activated through the app

To be decided:

• Target tolerances
• Complete component list
• Board size
• Battery size

General Flowchart:


If you have any ideas, respecs, or if you want to contribute, leave a reply!

 

[Gip-Gip]

Looking at the ATTINY-84 I plan to use, I have approx. 4 pins I can use for stuff like chute deploy, location buzzers, etc. etc. The rest of the pins will be used for UART, the crystal clock, and the reset line

 

[Gip-Gip]

For the accelerometer/axial accelerometer I'm going with an ICM-20602; that should provide the sample rate needed, and it provides standard accuracy for the pricepoint. As for memory, I'm going with a single FM24V10 IC, which provides enough memory at lest for the prototype. It's possible that less ram is required, which can be scaled down as needed (since this is an expensive IC), but for prototype purposes this should do the trick.

 

[Gip-Gip]

I made the first revision of the schematic. Going to read over it for errors and post it tonight. Next day I have off I'll get the PCB laid out and a BOM together.

I'll try to make everything fit in an estes gnome, I bought one for testing purposes

 

[Gip-Gip]

Here's a revision 1 schematic, if anyone wants to look over it

 

[plugger]

Isn't bluetooth meant to be a short range wireless protocol? Given that I would expect it to be one of the worst wireless technologies to use for telemetry?

 

[Gip-Gip]

Isn't bluetooth meant to be a short range wireless protocol? Given that I would expect it to be one of the worst wireless technologies to use for telemetry?

It's not meant to keep a constant connection, rather it's so you can start recording flight data from a distance and receive flight data without needing a cable

Also if it gets stuck in a tree or somewhere inaccessible it's still possible to download flight data

 

[tim cubbedge]

30' doesn't give you a lot of wiggle room!

 

[gtg738w]

30' doesn't give you a lot of wiggle room!

Bluetooth has evolved somewhat over the last 30 years... Modern implementations are in the hundreds of feet and extremely power efficient. Very well suited for arming and data download functions. There are also new standards that will offer 1km+ but it will be a while before handsets catch up for practical use. Expect to see a lot more Bluetooth in the future, use for telemetry is probably closer than we think.

 

[Gip-Gip]

30' doesn't give you a lot of wiggle room!

True. You'd have to have it stuck up a fairly large tree though for bluetooth to not be enough though, at least that's my opinion (whether or not it's true I have yet to test)

Granted when choosing bluetooth I was just thinking of something that would be more convenient than USB yet still practically possible with my level of experience

For example I think being able to control and view the logger from a phone or tablet is beneficial when doing stuff out in the field, and even if you want to use your laptop most have bluetooth adapters aswell.

Also bluetooth interface chips are small, low energy, and easy to implement

If you have a preferred wired/wireless protocol, post it and I can look into it

 

[neil_w]

I don't see why this is any different/worse than an altimeter with bluetooth, which uses it for the exact same purpose. It's convenient, but still assumes that you have recovered the rocket.

I'm more curious about the limitation of 16g, which seems almost uselessly low.

 

[Gip-Gip]

I don't see why this is any different/worse than an altimeter with bluetooth, which uses it for the exact same purpose. It's convenient, but still assumes that you have recovered the rocket.

I'm more curious about the limitation of 16g, which seems almost uselessly low.

I was just poking around at the idea of a logging Apogee board, more or less. It isn't real time telemetry, but I mean if something happens and you are within 30ft of the board it can help to get some insight into what happened

Plus, I have this board designed for small LPR rockets. 16g is the maximum recordable acceleration for most commonly available accelerometers, and I don't know of many LPRs that go above 16g when accelerating. Correct me if I'm wrong though.

I can look into other accelerometers as well if it really is that useless

 

[gtg738w]

I was just poking around at the idea of a logging Apogee board, more or less. It isn't real time telemetry, but I mean if something happens and you are within 30ft of the board it can help to get some insight into what happened

Plus, I have this board designed for small LPR rockets. 16g is the maximum recordable acceleration for most commonly available accelerometers, and I don't know of many LPRs that go above 16g when accelerating. Correct me if I'm wrong though.

I can look into other accelerometers as well if it really is that useless

16g is not at all useless. A lot of flights won't touch that and even if you do it will just clip briefly while it's over. Just think about how you're using the data and what will happen if it shows 16 when it should be 18 etc...

 

[neil_w]

I was just poking around at the idea of a logging Apogee board, more or less. It isn't real time telemetry, but I mean if something happens and you are within 30ft of the board it can help to get some insight into what happened

Plus, I have this board designed for small LPR rockets. 16g is the maximum recordable acceleration for most commonly available accelerometers, and I don't know of many LPRs that go above 16g when accelerating. Correct me if I'm wrong though.

I can look into other accelerometers as well if it really is that useless

Sorry, overstatement on my part. Certainly most of my flights are less than 16g, and that isn't useless. But it is easy enough to exceed. Here's a sim I have open right now, a 3 oz rocket with a 24 mm mount:

Even a C5-3 is estimating over 16g.

 

[gtg738w]

Sorry, overstatement on my part. Certainly most of my flights are less than 16g, and that isn't useless. But it is easy enough to exceed. Here's a sim I have open right now, a 3 oz rocket with a 24 mm mount:
View attachment 457599
Even a C5-3 is estimating over 16g.

Again, depends on what you’re using the data for... BP motors have that initial spike that is pretty short. If you’re integrating for velocity you might miss a couple percent. Even something extreme like an Estes Goblin on an F44 only missed the sim velocity by ~25% with a 16g chip. In reality it probably saw something around 50-60g peak. If you’re using it as the only sensor for a deployment system, it’s a bit different but for a hybrid system or just admiring the data, 16g is quite useful.

 

[neil_w]

Again, depends on what you’re using the data for...

Fair. I was thinking of simply finding out max acceleration, where the value of that spike is the number of interest.

 

[Gip-Gip]

Sorry, overstatement on my part. Certainly most of my flights are less than 16g, and that isn't useless. But it is easy enough to exceed. Here's a sim I have open right now, a 3 oz rocket with a 24 mm mount:
View attachment 457599
Even a C5-3 is estimating over 16g.

I don't think it would hurt me to look at higher rated accelerometers. Granted, a decent MEMS with a 16g max readable is like $4, at most, while more expensive ones are not only more expensive but also significantly larger

 

[neil_w]

I don't think it would hurt me to look at higher rated accelerometers. Granted, a decent MEMS with a 16g max readable is like $4, at most, while more expensive ones are not only more expensive but also significantly larger

Don't change it just on my behalf. I was just curious why the range was so limited.

 

[Gip-Gip]

Don't change it just on my behalf. I was just curious why the range was so limited.

No problem for me to look into it. Granted, I doubt it'll be of too much use to put a 60+ g accelerometers when I'm developing this board for fairly small rockets. Not saying I don't want to develop a bigger board though, but first things first I should probably get familiar with smaller stuff

 

[Reinhard]

What's the reason for for attaching everything via the UART/I2C bridge in the RN4871? Have you tested that, especially with 1ksps data rate? I'm wondering more about latency than bandwidth.
For what it's worth, some friends weren't happy with their experiences with a somewhat similar arrangement (SPI/I2C bridge within the MPU-9250).
Have you considered using a slightly bigger micro controller, that supports both UART and I2C at the same time?

Reinhard

 

[Gip-Gip]

What's the reason for for attaching everything via the UART/I2C bridge in the RN4871? Have you tested that, especially with 1ksps data rate? I'm wondering more about latency than bandwidth.
For what it's worth, some friends weren't happy with their experiences with a somewhat similar arrangement (SPI/I2C bridge within the MPU-9250).
Have you considered using a slightly bigger micro controller, that supports both UART and I2C at the same time?

Reinhard

I actually haven't tested the latency. Probably not too good if I had to guess.

If the first proto has latency issues there are two pins left on the ATTiny84 I can attempt to turn into I2C pins, and even if that doesn't work no biggie finding a different MCU

 

[Gip-Gip]

Don't change it just on my behalf. I was just curious why the range was so limited.

Looked at the accelerometers provided by mouser.com, there's a 100g accelerometer at $11 and a 24g at $5, but the bit depth is the same as the 16g at 16 bits. in other words, there is a resolution trade-off, especially for the 100g.

At $50, there are 20 bit accelerometers with similar range, but if I'm honest I could develop a better board for the $50 range. Maybe some day, but I'm just looking for something to start with here.

Out of curiousity, is there a favorite among accelerometer/IMU/gyro manufacturers as far as I should be concerned?

 

[Bruce]

Again, depends on what you’re using the data for... BP motors have that initial spike that is pretty short. If you’re integrating for velocity you might miss a couple percent. Even something extreme like an Estes Goblin on an F44 only missed the sim velocity by ~25% with a 16g chip. In reality it probably saw something around 50-60g peak. If you’re using it as the only sensor for a deployment system, it’s a bit different but for a hybrid system or just admiring the data, 16g is quite useful.

View attachment 457610

For the FlightSketch, is there any chance that the software could be tweaked so that the acceleration data graph is visible on the PC rather than just on the phone?

 

[BEC]

For the FlightSketch, is there any chance that the software could be tweaked so that the acceleration data graph is visible on the PC rather than just on the phone?

I should let Russ answer this, but it is in work (an update to the web log so you can see it there).

On the range thing....I've gotten data from a descending FS Mini overhead at distances over 200 feet.

 

[Reinhard]

Looked at the accelerometers provided by mouser.com, there's a 100g accelerometer at $11 and a 24g at $5, but the bit depth is the same as the 16g at 16 bits. in other words, there is a resolution trade-off, especially for the 100g.

At $50, there are 20 bit accelerometers with similar range, but if I'm honest I could develop a better board for the $50 range. Maybe some day, but I'm just looking for something to start with here.

Out of curiousity, is there a favorite among accelerometer/IMU/gyro manufacturers as far as I should be concerned?

I wouldn't worry too much about resolution. A 10bit ADC worked well for the 50g sensor in the R-DAS.

Reinhard

 

[Gip-Gip]

I wouldn't worry too much about resolution. A 10bit ADC worked well for the 50g sensor in the R-DAS.

Reinhard

Interesting. I'm not sure if I want to use a barometer or just use accelerometer data for velocity/altitude calculation, hence the 16 bit IMU

 

[plugger]

It's not meant to keep a constant connection, rather it's so you can start recording flight data from a distance and receive flight data without needing a cable

Also if it gets stuck in a tree or somewhere inaccessible it's still possible to download flight data

Ah, fair enough. I took the 'telemetry' literally, but if you're just using it for short range comms it should be fine.

Bluetooth has evolved somewhat over the last 30 years... Modern implementations are in the hundreds of feet and extremely power efficient. Very well suited for arming and data download functions. There are also new standards that will offer 1km+ but it will be a while before handsets catch up for practical use. Expect to see a lot more Bluetooth in the future, use for telemetry is probably closer than we think.

From my perspective if you're going to implement remote arming you'd be better off using wifi instead of bluetooth. Same frequency, longer range, still very small form factor. You're correct that bluetooth has evolved it's worth remembering it was designed as a personal area networking standard to replace serial connections. And while you can get 100 meters on Bluetooth it's recommended for ranges around 10 meters or less. Specifically, the unit Gip-Gip is using is rated for 10 meters unless you add on an external antenna. That's open air as well so I expect range would be somewhat reduced in application.

 

[Gip-Gip]

Ah, fair enough. I took the 'telemetry' literally, but if you're just using it for short range comms it should be fine.


From my perspective if you're going to implement remote arming you'd be better off using wifi instead of bluetooth. Same frequency, longer range, still very small form factor. You're correct that bluetooth has evolved it's worth remembering it was designed as a personal area networking standard to replace serial connections. And while you can get 100 meters on Bluetooth it's recommended for ranges around 10 meters or less. Specifically, the unit Gip-Gip is using is rated for 10 meters unless you add on an external antenna. That's open air as well so I expect range would be somewhat reduced in application.

I mean for LPR the arming range isn't that far either. Wifi may work better for this job, I just haven't tested it.

I'd say the arming range when I'm setting up a rocket is approx. 20ft or so? Maybe 40ft. I haven't fired a rocket in a while sadly, I just got some Estes stuff to get back into it.

When I get deeper into more powerful rockets I'd love to work on something more complex and feature packed, but I also just don't have the experience flying rockets to justify making a board so complex. I'd at least like to get hands on other boards to understand what I can improve and what people like/dislike about certain boards

Unrelated, I really want to be able to fit the board onto a gnome, not for practical purposes but because I want to see how small I can make it. At least with a basic altimeter I can make stuff very small

 

[Gip-Gip]

Did some quick math, here are the expected accuracies, drifts, etc

For the IMU I chose, the ICM-20602, the noise is 1mg(RMS). Therefore the velocity drift is expected to be at 0.0098 m/s/s. This is with a max readable acceleration of 16g

The only IMU I could easily find with more than a 16g limitation, the LSM6DSO32TR(with double the max readable acceleration, at 32g), has a 5.2mg(RMS) noise floor. The velocity drift is 0.0529 m/s/s.

Here's a table with the expected tolerances, accelerometer alone

Seconds since arming	ICM-20602 Velocity Error	Apogee Error	LSDM6 Velocity Error	Apogee Error
60 s	0.588 m/s	17.64 m	3.174 m/s	95.22 m
120 s	1.176 m/s	70.56 m	6.348 m/s	380.88 m
300 s	2.94 m/s	441 m	15.87 m/s	2380.5 m
600 s	5.88 m/s	1764 m	31.74 m/s	9522 m

I'm really tempted to go without a barometer if the ICM-20602, at least for the small flights I'm most likely to go for that's a perfectly fine velocity/apogee error for me.

 

[Gip-Gip]

PCBs are on the way, by far the ugliest PCB work I've done yet but gets the job done for a prototype. Should only be 2.5 weeks till all the parts arrive now