If different outboards are going at different times, you would need a separate channel for each time. A Raven plus one of these would do the trick for three separate airstarts plus dual deploy recovery.
Featherweight Tilt checker/timer
- Thread starter Adrian A
- Start date
Help Support The Rocketry Forum:
Update: I'm almost ready to place an order to manufacture a prototype PCB for the tilt checker board, a programmer/tester board for it, and a USB interface/battery charger board that will work with it.
I found a nice little set of board-to-board connectors that will make it a snap to connect the tilt checker board to a computer via the USB interface board. I decided while I'm at it, to put some header pads on 0.1" centers s on the interface board connected to the UART Tx and RX lines to make it easier for someone to connect to the tilt checker board for data. Or a data dumper or something. I don't think I'll have the processor throughput to output data all that fast in flight, but I should be able to manage some data that way.
I have a prototype PCB board for another project that should arrive tomorrow, and I think I'll wait to check that one out before I place this order. If I need to do a quick re-spin on the board that's coming tomorrow, I could do that for free by including it with this order of prototypes.
I found a nice little set of board-to-board connectors that will make it a snap to connect the tilt checker board to a computer via the USB interface board. I decided while I'm at it, to put some header pads on 0.1" centers s on the interface board connected to the UART Tx and RX lines to make it easier for someone to connect to the tilt checker board for data. Or a data dumper or something. I don't think I'll have the processor throughput to output data all that fast in flight, but I should be able to manage some data that way.
I have a prototype PCB board for another project that should arrive tomorrow, and I think I'll wait to check that one out before I place this order. If I need to do a quick re-spin on the board that's coming tomorrow, I could do that for free by including it with this order of prototypes.
Update: The order for the prototype boards is placed now.
Rocketeer Gator
Well-Known Member
- Joined
- Aug 12, 2010
- Messages
- 806
- Reaction score
- 3
subscribed....since one of these days this will come in handy building one of these......scaled down a tad.
Update: The prototype board components are on order also.
- Joined
- Jun 6, 2011
- Messages
- 7,562
- Reaction score
- 1,159
You Rock(et) Mr. A. Thx!
The comment I was responding to was withdrawn, and I'm doing the same.
Last edited:
stealth6
insert witty tagline here
I myself am 100% with you on this Adrian.
Please keep doing what you do, the way you do it. It's appreciated.
s6
Larry Curcio
Well-Known Member
- Joined
- Mar 5, 2009
- Messages
- 538
- Reaction score
- 3
Yes. It looks like a spectacular project - particularly if you can get anywhere near your target price. Very impressive.
jms
Well-Known Member
- Joined
- Jun 5, 2011
- Messages
- 298
- Reaction score
- 0
Hey Adrian, out of curiosity, and since I didn't see you post it anywhere in this thread: what microcontroller are you using?
If you can tie into the uC's RX/TX lines easily, you could run an OpenLog (microSD card, and 3 pins: 3.3v (I'm assuming you're using 3.3), GND and RX)). Then you can run it at 9600-115200 or whatever, and good up to 16GB. The OpenLog is pretty cheap, and if you're putting hundredthow headers on anyways, you could definitely pop one on with some prototyping jumpers just to see if your uC can keep up.
As always, whether its your builds or your electronics....awesome work dude.
Last edited:
- Joined
- Jan 19, 2009
- Messages
- 14,955
- Reaction score
- 1,287
Looks to be a product in the Z-80 line! Holy cow, I'm pretty sure I still remember most of that instruction set....
-Kevin
That's cool, good idea. See, ideas like this are why I started this thread before I started production. I may rearrange the interface board header pins a bit to make it easier for someone to add one of these on if they want. The only real question mark is the fact that it's looking for 3.3 Volts on the input. I'm running the tilt checker board at 3.0V for maximum accuracy on the gyro, but it's worth a shot to see if it can be hooked up directly anyway. If not, there are some work-arounds that could be done for the power. My plan is to use whatever extra RAM I have left over to record the tilt or attitude at a relatively low rate, and then if someone has the optional interface board, they could at least download that data as long as the unit stays powered. This would provide an option for infinitely more space, and it would be non-volatile. I'm not sure if I'll have many extra computational cycles available to shift a lot of data to the UART, but we'll see.
That's especially funny to me, because I know no assembly whatsoever; I just program it in C.
- Joined
- Jan 19, 2009
- Messages
- 14,955
- Reaction score
- 1,287
jms
Well-Known Member
- Joined
- Jun 5, 2011
- Messages
- 298
- Reaction score
- 0
Hey Adrian, that's cool. If you need to regulate the gyro at 3.0V for accuracy, you could use one of these little beggars:
https://content.solarbotics.com/products/documentation/cd00000971.pdf
That datasheet is just where I buy it, pretty sure Digi has them as well. Which I am fairly certain in another project I was feeding it 2.5v and getting 3.3v out. Most uart lines will be tolerant of 3.0V-ish, so I am guessing you'd be able to run it without issue, but then again, I am no engineer
I took a peek at that chip of yours, my god man did you solder that LQFP package yourself?! At 20Mhz I would guess that you have ample processing power to be able to push the UART data. But then again, a lot can change in milliseconds on a mach busting flight, I dig that.
https://content.solarbotics.com/products/documentation/cd00000971.pdf
That datasheet is just where I buy it, pretty sure Digi has them as well. Which I am fairly certain in another project I was feeding it 2.5v and getting 3.3v out. Most uart lines will be tolerant of 3.0V-ish, so I am guessing you'd be able to run it without issue, but then again, I am no engineer
I took a peek at that chip of yours, my god man did you solder that LQFP package yourself?! At 20Mhz I would guess that you have ample processing power to be able to push the UART data. But then again, a lot can change in milliseconds on a mach busting flight, I dig that.
That part isn't too bad. The only parts I solder myself are on prototypes. The production units are machine-assembled. The toughest one I have tried is TI's CC1101 chip. It has about half the pitch, and no leads.
The accuracy will depend in part on how quickly I can update the attitude. I'm shooting for 200-400 Hz, and there are 3 16-bit numbers I have to get from the chip and 27 multiplications that have to be done each time. If I use quaternions, maybe less, but I haven't worked that out yet.
- Joined
- Jan 18, 2009
- Messages
- 5,937
- Reaction score
- 579
Assembly language? ... humph!
21003C
11013C
01FF03
3620
EDBO
I still remember that machine code sequence from typing it some many times. My first TRS-80 didn't have enough memory to run an assembler, so I typed everything in as hex code.
-- Roger
UhClem
Well-Known Member
- Joined
- Feb 6, 2009
- Messages
- 2,052
- Reaction score
- 443
The only thing a Z8 shares with a Z80 is the "Z" and the "8".
UhClem
Well-Known Member
- Joined
- Feb 6, 2009
- Messages
- 2,052
- Reaction score
- 443
27 is actually a bit high since you are multiplying by a 3X3 matrix that has 1's on the diagonal. So if you code the matrix multiply by hand you can knock that down to 18. On the other hand don't forget the additions. On a machine without a barrel shifter they can take a while. Before adding the mantissas the first step is to normalize the numbers so that the binary points are aligned. In this case order of evaluation can hurt you.
Consider one 3X3 vector multiply. You get to skip one multiplication but then you multiply two elements of your rotation matrix by small numbers. The result will be that two of the products will in general have much smaller magnitude than the third. If you add one small number to the larger and then add the next small number this will take longer to execute (more bit shifts) than if you add the two small numbers together before adding to the large one.
It is also possible that these additions might not be as accurate as you like because of the magnitude differences in the numbers.
My inclination is to just use 32-bit floats for this. Also I'm going to study up on quarternions because I have read that they're more computationally efficient and don't need to be re-normalized as often.
Update: The prototype boards have arrived, but right before I got them I discovered that I made a layout error that will prevent me from checking out the gyro interface until the next rev. I'm checking out the other new products I have on that panel, so I can have good revisions to all of them before sending out for the next panel of prototypes. So it's looking like probably a couple of weeks before I have hardware that's ready for the full-up firmware development of the gyro tilt checker.
The good news is that this will give me an opportunity to prototype another couple of products, sooner rather than later.
The good news is that this will give me an opportunity to prototype another couple of products, sooner rather than later.
thomas
Well-Known Member
- Joined
- Dec 16, 2011
- Messages
- 293
- Reaction score
- 23
When you think about using openlog you should think about logging speed.
Using 1 bit spi interface to an SD card has a high latency .So you have to buffer data, when you like to have some continuous logging.
Another some general point:
A safety device should not inhibit a ignition it should allow it.
Orientation sensing is quite common in multirotor rc models.
https://www.multiwii.com/
Might be helpful, but in rocketry you need high update rates and acceleration is not dominated by gravitation.
For future projects an InvenSense MPU-6050 might be useful since it can do the motion processing.
But up to now the features are not documented.
Using 1 bit spi interface to an SD card has a high latency .So you have to buffer data, when you like to have some continuous logging.
Another some general point:
A safety device should not inhibit a ignition it should allow it.
Orientation sensing is quite common in multirotor rc models.
https://www.multiwii.com/
Might be helpful, but in rocketry you need high update rates and acceleration is not dominated by gravitation.
For future projects an InvenSense MPU-6050 might be useful since it can do the motion processing.
But up to now the features are not documented.
Last edited:
The data rates produced by this won't be very high; just time vs. degrees and perhaps igniter continuity.
I'm not sure what you have in mind here. I think you could call the FET in series with the ignition system an inhbit (in NASA safety terminology) or a switch that allows the ignition to happen when the tilt is small enough. The switch is passively open (off) when the board is off. After that it's controlled by the microcontroller and only closed under safe conditions.
I looked into it, and it's actually a bit worse than just not documented. The motion processing code has to be stored on an off-line microcontroller and loaded onto the chip. That wouldn't be a show-stopper except that the they only provide the loader code as an executable for a particular microcontroller which is not one I use. Instead, I'll use algorithms to propagate the attitude using the gyros that are pretty well documented by Bill Premerlani and others. I'm also using a gyro that has better zero-rate temperature stability and a little less gain error than the Invensense ones, as well as a nice 32-deep FIFO buffer, self-test, and other useful features.
thomas
Well-Known Member
- Joined
- Dec 16, 2011
- Messages
- 293
- Reaction score
- 23
Actually I had the things in mind you mentioned.
That while the system is off a ignition should not be possible.
Maybe that was just some misunderstanding of the meaning of inhibit.
What Gyros do you use?
I use gyros from ST Micro. The white paper a few posts ago shows the performance.
Last week I did some rough calculations on how much processor usage should be required to propagate the attitude using quaternions. If my calculations were anywhere close, it showed that I should have a reasonable amount of processor capability left over. I also found a flash memory chip that should be fairly easy for me to integrate into the design without adding a lot of cost. So for the next rev of the prototype, I'm going to add the flash chip, and I'm planning to record the following data at 40 Hz:
Roll rate
Flight angle
Accel X
Accel Y
Accel Z
Continuity V
Flight event status
It's nowhere near the data recording capability of a Raven, but it should be sufficient to explain what the board did, and why, and I won't have to figure out how to hook up somebody else's data logging board to get the test data I need.
Probably not, but maybe. We'll see how many processor cycles I have left over when it's done. I'll be getting about as much savings by using the built-in SPI interface rather than bit-banging.
Adrian,
Do you have an update on these?
Do you have an update on these?
Similar threads
