OSHW Bluetooth telemetry board discussion & spec-out

[Reinhard]

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.

Noise is not much of a problem, because you integrate your accelerometer data. The primary concern is nonlinearity and maybe things like offset drift.

Your table bases the error on "Seconds since arming". You can compensate your sensor offset right until liftoff, or at least keep the altitude and velocity values fixed to zero before liftoff is detected. This will reduce your errors significantly.

Reinhard

 

[gtg738w]

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?

Yes, The flight log page has been updated to match what is shown in the app. They now use the same chart package so everything looks familiar. The updates are tied to a couple of other features that are still in work so it may be a bit of a delay before it gets pushed to the main server. All of the existing flights have the data stored so they will be updated too.

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.

From what i've tested I don't think range is a factor. The trade is a MUCH lower power consumption for a slightly slower data transfer rate with Bluetooth. I'll have to let the hardware speak for itself but for what I fly I'd much rather have Bluetooth. Battery size is a much bigger factor for weight and volume than the altimeter itself.

 

[Gip-Gip]

Finally got most everything assembled and noticed I somehow lost my AVR ISP programmer.

Still waiting on the IMU, that's on backorder due to chip shortage and all that, but I have everything else assembled and ready for latency testing, among other things...



Even without programming I've figured out a few things I should change. First, As you can see, almost everything except the programming pins fit inside the gnome pictured, which I'm fairly impressed with. I could honestly trim them down and see how that goes, but I would also like to see if there is another way to connect this to a programming interface, perhaps like a card-edge style connector or something of that sort

Second, I wasn't sure how I would accomplish double sided pcb reflow soldering until I figured out you simply use a high temp solder paste on the first side and a low temp bismuth paste on the second side. With this knowledge I could move all the non-heat-sensitive passives to the back side of the PCB and all the ICs to the front.

Third, putting VIAs on the solder pads of the RN4871 is a bad idea, as all the solder flows to the ground/power planes. I should ignore KiCad's keepout zones for the part and stick to the manufacturer recommendations instead

Within the next week I should have the programmer and I'll be able to test the I2C latency of the RN4871. What I will most likely find is that the latency will probably be way too high for anything usable, and I will most likely have to either deal with a lower target sample rate, probably closer to 100hz, or worst case redesign the PCB to make the ATTINY84 the I2C controller instead of the RN4871.

Meantime, I'll either reorganize the repository and work on code standards, or just relax and wait for the programmer to come in

 

[jderimig]

Kinda late to this thread but you may want to consider the ICM20601, it has 32g range and maybe footprint compatible, i haven't checked.

 

[Gip-Gip]

Kinda late to this thread but you may want to consider the ICM20601, it has 32g range and maybe footprint compatible, i haven't checked.

Not late at all, still prototyping as far as things go. Also appears I don't have an option, as the ICM20601 is in stock and the ICM20602 has a 26 week lead-time

the noise is about 4x worse, meaning the drift will be pretty bad, but whether or not that truely matters will be down to testing

quick look at the data sheet shows the pins are identical

 

[jderimig]

The noise difference will not be relevant for your application. It gets integrated out when you process the signal. We are using it a project quite a bit more exacting than yours, it will be fine. Gaussian noise is good, it gives you more resolution when you oversample.

 

[Gip-Gip]

The noise difference will not be relevant for your application. It gets integrated out when you process the signal. We are using it a project quite a bit more exacting than yours, it will be fine. Gaussian noise is good, it gives you more resolution when you oversample.

Thanks for the suggestion!

Out of curiosity, what projects are you working on at the moment?

 

[jderimig]

Thanks for the suggestion!

Out of curiosity, what projects are you working on at the moment?

Primarily IMU work for more terrestial applications while trying to navigate the semi shortages.

 

[Gip-Gip]

All the parts are here, just need to finish the code (most likely going to be done by the end of the day) and I'll perform some latency tests

 

[Gip-Gip]

I wasn't able to get the I2C interface up and running before my work week started, but it is very likely the latency will be pretty bad, so a revision 2 is likely on the way.

I don't think I've posted it here before, but here's the github link: https://github.com/Gip-Gip/msbaker

 

[Gip-Gip]

Dissapointing news: the CR1025 doesn't supply enough current to power the circuit, by a long shot. Apparently coin cells don't supply much more than 1 or 2ma. I should've looked into it, but what baffles me is I made a prototype-prototype and it worked perfectly fine with a CR1632. Who knows.

Anyways, I have 2 choices: ditch the bluetoooth and just use the ATTINY(store data via USB or SD card or something), OR I can trade out the ATTINY+RS4871 all together and use an esp32 instead(using a boost converter and a AAA battery in place of a coin cell). I think I'm going to go for option A, primarily due to cost and size.

 

[Gip-Gip]

I've started developing a version of the board that utilizes the ESP32-D2WD chip, powered by a AAAA battery and a boost converter. Should be done with the prototype schematic within the next week or so; the ESP32 is significantly more complex than the ATTINY I'm used to

 

[Gip-Gip]

Prototype schematic is nearly done, just need to find the capacitor/inductor antenna matching values, and then I'll design the PCB

Same accelerometer, same FeRAM, but now utilizing an ESP32-U4WDH as the bluetooth controller/mcu. I wouldn't say it brings down the cost for the circuit, but it opens it up for a lot more possibilities

On the schematic, you'll see two connectors named PEPI and PEGI; standing for PCB-Edge Programming Interface and PCB-Edge GPIO Interface respectively.

• PEPI supports direct Flash flashing, JTAG, I2C monitoring and a UART interface
• PEGI supports 15 GPIO pins, which can be used for future expansions such as chute deployers, stage seperators, engine igniters, more i2c/spi buses, etc.

I still plan to use only BTLE, as it has a lower current draw than wifi, and with a lower current draw I can get away with a smaller battery, like a AAAA.

I need to still do some math on the total max current draw before I'm sure that's the battery I wish to use

What are your thoughts? Suggestions?

Schematic linked here:

https://raw.githubusercontent.com/Gip-Gip/msbaker/main/docs/schematic.png

 

[jderimig]

Why are you designing for a such a constrained battery size? Why not consider a very small 1s Lipo and dispense with the booster complexity?

 

[gtg738w]

BLE was designed for low power applications, you can definitely run a basic altimeter from a coin cell. Make sure you actually measure the current from each block, can be done with a voltmeter and suitable resistor. Most of the time there are very specific options that need to be set to hit the data sheet numbers. You may need to tune a bit to get the power down.

 

[Gip-Gip]

Why are you designing for a such a constrained battery size? Why not consider a very small 1s Lipo and dispense with the booster complexity?

Honestly not out of the question, though the booster circuit doesn't add too much and I'd need a voltage regulator eitherway. However the weight would be fairly significantly improved, I'll take a look at it

BLE was designed for low power applications, you can definitely run a basic altimeter from a coin cell. Make sure you actually measure the current from each block, can be done with a voltmeter and suitable resistor. Most of the time there are very specific options that need to be set to hit the data sheet numbers. You may need to tune a bit to get the power down.

Could do that, but the RN4871 datasheet reports a max current of 10mA when transmitting/receiving, attiny around 3mA but could be brought down less than 1mA if I divided the clock speed by 8.

All this adds up over 1mA of course, so I'm not sure if this is worth improving on. I'm intrigued by the ESP-32 I'll admit though, since it reduces the chip count and has a lot more power behind it. Granted, I'm still learning a lot about it; for instance, I actually need the ESP32-U4WHD instead because for some reason the D2WD's internal flash requires the IO to operate at 1.8 instead of 3.3.

Tomorrow I'll look into lithium cells, they're probably better overall weight and power wise

 

[Gip-Gip]

Just glancing over two datasheets, AAAA batteries of the energizer brand have approx. 300mAh worth of juice when discharged at 300mA(roughly 74ma less than our estimated maximum current draw, with all ICs active, bluetooth scanning, each LED on), and each AAAA battery weighs 6.5g. This LiPo cell I found by googling "small lipo" has about 40mAh of juice and a weight of "less than 5g" https://www.sparkfun.com/products/13852

Note: when calculating max. current draw, I added up all the max currents(170) and multiplied them by 3.3/1.5, something something conservation of energy something something P=VA

The AAAA battery still look appealing, but I would still like to hear opinions on it

 

[OverTheTop]

Don't forget to factor in the efficiency of the boost converter into your equation. A reasonable buck converter (stepdown) is around 85%, but boost converters are usually less efficient. Either look up the efficiency number or use 70% as the figure. That heat loss will shorten your time on the battery.

 

[Gip-Gip]

Don't forget to factor in the efficiency of the boost converter into your equation. A reasonable buck converter (stepdown) is around 85%, but boost converters are usually less efficient. Either look up the efficiency number or use 70% as the figure. That heat loss will shorten your time on the battery.

True, but those are pulse current numbers, average according to testing is closer around 2ma if I remember correctly

 

[OverTheTop]

Whether measured or calculated you can take it into account. A lot of those small switchmode converters are surprisingly inefficient. If you are really pushing battery limits it should be taken into account.

 

[Reinhard]

Prototype schematic is nearly done, just need to find the capacitor/inductor antenna matching values, and then I'll design the PCB

Same accelerometer, same FeRAM, but now utilizing an ESP32-U4WDH as the bluetooth controller/mcu. I wouldn't say it brings down the cost for the circuit, but it opens it up for a lot more possibilities

On the schematic, you'll see two connectors named PEPI and PEGI; standing for PCB-Edge Programming Interface and PCB-Edge GPIO Interface respectively.

• PEPI supports direct Flash flashing, JTAG, I2C monitoring and a UART interface
• PEGI supports 15 GPIO pins, which can be used for future expansions such as chute deployers, stage seperators, engine igniters, more i2c/spi buses, etc.

I still plan to use only BTLE, as it has a lower current draw than wifi, and with a lower current draw I can get away with a smaller battery, like a AAAA.

I need to still do some math on the total max current draw before I'm sure that's the battery I wish to use

What are your thoughts? Suggestions?

Schematic linked here:

https://raw.githubusercontent.com/Gip-Gip/msbaker/main/docs/schematic.png

Two quick observations:
1) It doesn't seem like you need the 1.8V supply. The ICM-20601 also works with only 3.3V
2) Take a look at net labels. E.g. for your connectors you can save a lot of wires in the schematic. And you can understand their pinout at a glance instead of following all those wires. It depends mostly on your preferences though.
https://www.baldengineer.com/kicad-bus-labels-and-global-labels.html

Just glancing over two datasheets, AAAA batteries of the energizer brand have approx. 300mAh worth of juice when discharged at 300mA(roughly 74ma less than our estimated maximum current draw, with all ICs active, bluetooth scanning, each LED on), and each AAAA battery weighs 6.5g. This LiPo cell I found by googling "small lipo" has about 40mAh of juice and a weight of "less than 5g" https://www.sparkfun.com/products/13852

Note: when calculating max. current draw, I added up all the max currents(170) and multiplied them by 3.3/1.5, something something conservation of energy something something P=VA

The AAAA battery still look appealing, but I would still like to hear opinions on it

Sparkfun is not very precise with their "less than 5g" spec. You can get roughly 30-40mAh per gram when using LiPos. That's a higher energy density than your AAAA cell. And you can use a simpler voltage regulator. By the way, switch converters can be rather inefficient when used at low loads, so they are not automatically more efficient than a linear regulator.

Reinhard

 

[OverTheTop]

Thanks for posting the schematic for review. It is always nice to have other sets of eyes over them. You get a better outcome that way.

A couple of comments. I suspect the diagram would have benefited from the next size paper up and going landscape. The existing one looks cramped.

Don't forget you can annotate extra info like expected current draw and other relevant information on the schematic.

As per Reinhard's comments using net names, especially near connectors, can be helpful during debugging. You can also just sketch and annotate a diagram near the connector on the diagram. If you do this make sure it is the same layout as the physical layout, to assist with debugging.

Don't be afraid to label connectors and other features that will help people less familiar with the circuit navigate it.

I hope the project goes well for you.

 

[Gip-Gip]

Two quick observations:
1) It doesn't seem like you need the 1.8V supply. The ICM-20601 also works with only 3.3V
2) Take a look at net labels. E.g. for your connectors you can save a lot of wires in the schematic. And you can understand their pinout at a glance instead of following all those wires. It depends mostly on your preferences though.
https://www.baldengineer.com/kicad-bus-labels-and-global-labels.html



Sparkfun is not very precise with their "less than 5g" spec. You can get roughly 30-40mAh per gram when using LiPos. That's a higher energy density than your AAAA cell. And you can use a simpler voltage regulator. By the way, switch converters can be rather inefficient when used at low loads, so they are not automatically more efficient than a linear regulator.

Reinhard

I use the 1.8v regulator to keep the noise away from the accelerometer(hence VDDIO being greater than VDD, I checked with TDK and they said it won't hurt the chip), it would honestly probably cost about as much in LC components to denoise the ESP-32, though I'm just guessing and I could be wrong

Also yeah I'll change the wires to nets, I've heard arguments both ways but with this amount of pins it just makes more sense to at least do nets for the connectors

I noticed on the datasheet for the switch mode converter that it is about only 40% efficient at low loads, so effectively a linear regulator at that point. I now have the time to look at LiPos in greater depth, good chance I'll switch to one

Thanks for posting the schematic for review. It is always nice to have other sets of eyes over them. You get a better outcome that way.

A couple of comments. I suspect the diagram would have benefited from the next size paper up and going landscape. The existing one looks cramped.

Don't forget you can annotate extra info like expected current draw and other relevant information on the schematic.

As per Reinhard's comments using net names, especially near connectors, can be helpful during debugging. You can also just sketch and annotate a diagram near the connector on the diagram. If you do this make sure it is the same layout as the physical layout, to assist with debugging.

Don't be afraid to label connectors and other features that will help people less familiar with the circuit navigate it.

I hope the project goes well for you.

I actually had it landscape before, but I wanted to print it out without having to squint really hard to see the components

I'm going to go ahead while I'm redoing the circuit and annotate the current draw, pin capacitance, and all that fun stuff

I appreciate it though! Should be finished with the revisions by the end of the day

 

[Gip-Gip]

Finished with the revision 2.1 schematic, more or less!

Notable changes include:

• Revised programming interface to make it compatible with the ESP32-PROG programmer, Reduced GPIO connector to reflect the loss of some GPIO pins
• Changed the power supply to work off LiPo batteries, with a linear regulator and a Molex PicoBlade connector for small LiPo batteries
• Summed all of the current draws of each IC, coming to a grand total of 205mA max current. When choosing a LiPo make sure to account for this

The only things left to do include: overview, PCB layout, and antenna matching(Hence L1, C5 and C6 not being defined yet)

Schematic can be found here: https://raw.githubusercontent.com/G...f262ff33ad96f65bc395d43c0e/docs/schematic.png

 

[Gip-Gip]

PCB and Schematic are almost completely finished, basically been making 100% sure there's nothing I messed up since it's a fairly compact and complex board, relatively

I'm also going to have to build an anechoic chamber since I have to do all the RF circuitry, which should be done in about a month or two, about time all the parts arrive

Should be done and have parts ordered by the end of the day

 

[Gip-Gip]

Schematic and board are 100% finished and parts are ordered!

I am going to buy a few variety surface mount inductors and capacitors to tune the antenna but other than that, all that's left to do is program it and hope for the best!

A few things I'm certain I'll change but I want to get some hardware in my hands before I make anymore changes

 

[Gip-Gip]

Don't know if I said this already, but the github is more or less up at this point and while I'm waiting for parts I'll continue to organize it and document the whole thing

Link is here: https://github.com/Gip-Gip/msbaker

 

[Gip-Gip]

Just finished testing my boards, I had some issues soldering the fine pitch ESP32 so sadly they're all bricks but I think I learned what I did wrong and I went ahead and ordered some more. Will touch base in 2 weeks