Next-Gen Raven Development Thread

[manixFan]

While I like the Power Perch, it adds a significant amount of width to the Raven which defeats one of its primary advantages - the small size. For my latest builds I had to go with a 3rd party product that was oriented vertically to get easy to use wiring connectors that would fit my space and then I had to add in a magnetic switch for arming. While not really part of your redesign, a Power Perch that was designed to minimize width and still include the battery and magnetic switch would be great and not duplicate other offerings. In my setups I really can't use your A/V bays which would otherwise solve this issue.

One thing I really like about the Raven is that it is just an altimeter. I really prefer to keep my electronics separate. So for me you are on the right path by keeping it the same functionality-wise and not trying to add in a lot of extra features that I'd rather keep separate. But if there was some sort of an on-board connector to allow for flight data to be output to another device for telemetry that would be great.


Tony

 

[Adrian A]

Slight hijack, here. I derive the velocity from the baro altitude by myself, but of course, it is noisy. What is a good reference for filtering/smoothing algorithms?

I don't have a reference, but a simple and effective filter is to update the filtered value by moving the filtered value only partway toward the latest sample. Mathematically it looks like filtered_value = filtered_value + (meas - filtered_value)/Gain. The higher the gain, the more smoothing there is, and the longer the lag.

Stop calling channels by functions that are re-assignable.....what I mean by that is just NUMBER the channels like everyone else. Calling a channel "MAIN" and one "APOGEE" gets really confusing when those channels are NOT for that function.
My usual setup is CH1 = Apogee; CH2=Apogee backup (delayed a 1/2 sec); CH3=Low Altitude; CH4=Lower Altitude.
This way I expect the channels to fire in numerical order and the setup is as clear as possible.

While I agree it would be cleaner to do as you suggest, it would reduce the ease-of-use for those (probably the large majority) who want to just hook up the altimeter out of the box without changing settings. The fraction of people who would want to use "Apogee" and "Main" channel for something other than Apogee and Main are a smaller minority still, and if they're well-versed enough to be annoyed by pre-labeled outputs, they're also capable of working around it.

But if I'm misreading the audience and there are a lot of people who have been annoyed at the pre-labeled outputs, feel free to chime in. (In either case, changing them would be on a future product due to wanting to maintain continuity with the current Raven product base)

 

[mikec]

The fraction of people who would want to use "Apogee" and "Main" channel for something other than Apogee and Main are a smaller minority still, and if they're well-versed enough to be annoyed by pre-labeled outputs, they're also capable of working around it.

I think you've made the right call. Even for most of the flights where I use all four outputs (multistage, usually) I'm still using apogee and main for those purposes. FWIW, Altus Metrum also labels their channels apogee and main on the Telemega.

 

[Nathan]

You already got the #1 thing on my wish list: holes for 4-40 size mounting screws.

 

[kjm]

Hi Adrian -- My favorite altimeter. I own 2 Ravens, and will be looking for another one after last weekend's umm..."events" (separation, not-altimeter related). As an engineer I understand the design constraints on the new model. My Raven wishlist has always included two things - more accurate, less noisy accelerometer (yay!) and a small FIP upgrade.

Please upgrade the FIP to include a "flight comments" field. I think many of us like to store comments about the flight along with the data. When reviewing the flight data at later times, having some comments about the flight greatly helps in understanding the data. Currently I put some of that in the file name:

"04_30_18_magnum_on K550W_and_2x_H180W_airstarts_at_snow_ranch_arced_off_pad.fipa".

But having a comment field in FIP would certainly be an improvement.

Thanks,
Kevin.

 

[cwbullet]

But having a comment field in FIP would certainly be an improvement.

Concur. Flight comments would be nice. Being able to add flight info to the file after the flight would be awesome.

 

[OverTheTop]

I think you've made the right call. Even for most of the flights where I use all four outputs (multistage, usually) I'm still using apogee and main for those purposes. FWIW, Altus Metrum also labels their channels apogee and main on the Telemega.

+1

As for USB connectors, the C type will always plug in first time. The micro type is nearly always presented to the connector in the wrong orientation the first time . Not sure how many of the older laptops and computers support the C standard or what backward compatibility is like.

I have six of these altimeters. Looking forward to the new version!

 

[cwbullet]

I think there might be some confusion. A "C" type connector is just a connector. You can get a cable to go from the "A" type connector to a "C" type. Most new computers come with "A" and "C" step connectors on their motherboard. The opposite end is what would plug into the Raven. You can buy a cable to go "A" to "B", "A" to "C", "A" to "Micro", and "A" to "Mini". Similarly, you can buy the same cable from "C" to just about any of the same connectors. I have a PC and Mac with Type "A" connectors on the motherboard and have not issue using an "A" to "C" 3.0 cable to charge and update my tablet. Usually, the key is the version number (1.1, 2.0, 3.0, or 3.1).

 

[plugger]

Good post Chuck. It reminded me of another reason why I prefer Micro-B. It's a smaller physical interface when compared to the Type C connector.

And although I doubt it would cause issues for the Type C connectors if used on the Raven (the cable interface end of the connection that is) I've found that C connectors accumulate dirt and such in the port. I never realised it was an issue until my old Nexus 5X phone stopped charging rapidly and wouldn't mount on a computer. It was only after I went in and cleaned the connector with a paperclip that it started working again. Micro-B doesn't have that issue, or at least I've never had that issue with Micro-B interfaces.

 

[cwbullet]

Good post Chuck. It reminded me of another reason why I prefer Micro-B. It's a smaller physical interface when compared to the Type C connector.

And although I doubt it would cause issues for the Type C connectors if used on the Raven (the cable interface end of the connection that is) I've found that C connectors accumulate dirt and such in the port. I never realised it was an issue until my old Nexus 5X phone stopped charging rapidly and wouldn't mount on a computer. It was only after I went in and cleaned the connector with a paperclip that it started working again. Micro-B doesn't have that issue, or at least I've never had that issue with Micro-B interfaces.

I could care less. I just want to explain the interfaces and the fact that you can pretty much buy a cable and converter to connect any of them. I just want the best product. The only benefit to a true "C" is faster charging but you need a device that can take advantage of it.

 

[plugger]

The only benefit to a true "C" is faster charging but you need a device that can take advantage of it.

Considering the Raven doesn't provide the ability to charge via the altimeter I too could care less.

 

[OverTheTop]

Thanks Chuck. I figured there would be some compaitbiliy, I just had never looked into it before. Got a new phone with the C plug last week.

 

[JimJarvis50]

Adrian, I think you did a great job selecting the programming variables in your original development. Unfortunately, there is not enough flexibility for more complex staged flights, and compromises are required. Probably not in the cards, but it would be nice to independently program each channel.

Jim

 

[AdAstraPerAspera]

Call me crazy, but I would stick to the mini USB connector. It is far more robust than the micro. No real experience with the new C type, but it looks small and delicate like the micro version. I have problems with micro devices getting messed up and not even charging, never mind passing data... Granted, that is with things like my phone that get significantly more use than my altimeters.

 

[cwbullet]

C is not delicate. It is more durable than a micro and maybe mini.

I do not think C is the way to go, but a lot of the reasons given why to not choose the C presented here are bogus. The reason to not choose the C is that it is less available and less supported at this time.

 

[plugger]

Hi Adrian,

I've been banging my head against the wall for the past week or so trying to wrap my head around how to configure a Raven 3 for a backup backup apogee deployment event above 100k' AGL where the baro sensor becomes useless. It's highlighted to me a significant issue with the current boards; specifically the lack of an easily attainable high altitude firmware feature. Given this would it be possible to supply Raven 4s with a standard and "High altitude" firmware option as part of the retail process? Personally I'd much prefer to be able to configure TVals over 51.2 seconds when compared to having a tenth of a second accuracy in my TVal configurations. Same goes for the AGL values, my preference is a larger but less accurate range when compared to less range overall.

For the record my current logic for the "backup backup" nominal apogee event is Baro only Apogee event + a 40 second delay. I came to this value by checking the sim to see when the rocket reached 100k' AGL, noted the time it took in simulation to get to that point, subtracted that figure from the total simulated time to apogee, and then added 6 seconds to provide the backup to the backup. Pretty? Not in the slightest. But it just might work...

Or, I could be completely mistaken. Does the above make sense to you? Apologies for the threadjack but it's at least slightly relate-able to the Raven 4 development...

 

[mikec]

Personally I'd much prefer to be able to configure TVals over 51.2 seconds...
For the record my current logic for the "backup backup" nominal apogee event is Baro only Apogee event + a 40 second delay.

I asked for that upthead but even that may not fit in the very constrained space of the micro he's using.

As for the backup, the right solution would be to use accelerometer apogee plus a smaller delay, if the accelerometer worked reliably. By the time you try to use baro measurements you might as well just use a pure timer IMHO.

 

[Andrew_ASC]

Keep it raven 3 sized or smaller. Please. This is like the go to altimeter for SEDS competition.

 

[tim cubbedge]

Keep it raven 3 sized or smaller. Please. This is like the go to altimeter for SEDS competition.

Did you read post #1?

 

[Andrew_ASC]

No.

 

[tim cubbedge]

No.

I figured as much.

 

[plugger]

I asked for that upthead but even that may not fit in the very constrained space of the micro he's using.

As for the backup, the right solution would be to use accelerometer apogee plus a smaller delay, if the accelerometer worked reliably. By the time you try to use baro measurements you might as well just use a pure timer IMHO.

Thanks Mike, I skimmed the thread and didn't realise you had already called it out so to speak. I understand Adrian's constraints in terms of not wanting to "reinvent the Raven" but from my understanding the Raven 2 High Altitude firmware eliminates the 0.1 second accuracy of the TVal option and instead gives you the option to configure whole seconds instead. Given the range is from 0 to 51.2 seconds at 0.1 increments that equates to 512 values which does make me consider it to be a board/hardware constraint. But by changing the increments to 1 second that would allow us a configuration range from 0 to 512 seconds. For most high altitude flights 51.2 seconds isn't near enough time from a "time to apogee" perspective. That's what's killing me on the Raven 3 config right now. I'd like to use it as a "pure timer" as you mention but I can't due to the fact that I need to configure a timer value in the range of 90ish seconds. Hence the idea of Baro apogee + 40 second delay.

Also, it seems that accelerometer drift becomes more significant the longer it takes to get to apogee. Given that I believe it's a less than optimal solution to put it mildly given the flight envelope.

 

[mikec]

Also, it seems that accelerometer drift becomes more significant the longer it takes to get to apogee.

I'm hoping that the new accel used in the Raven 4 will work better in this regard, but we'll see. For my high-alt Raven 3 flights, I programmed one channel for accel apogee plus some delay intended to bound the error, and another for baro apogee below the altitude where the baro still worked, and tied both of those channels to the same ematch so I would get deployment either with or without second-stage ignition. Of course the rocket CATOed during first-stage burn so we didn't get a chance to see if it would work at altitude.

 

[OverTheTop]

Any word on when the Raven4 will be available Adrian? I want to buy one or two. Would have gone the 3 but nil stock .

 

[Adrian A]

I

Call me crazy, but I would stick to the mini USB connector. It is far more robust than the micro. No real experience with the new C type, but it looks small and delicate like the micro version. I have problems with micro devices getting messed up and not even charging, never mind passing data... Granted, that is with things like my phone that get significantly more use than my altimeters.

I feel your pain with the USB micro connectors, having had problems on a recent project. Some micro connectors are better than others, though, and I think I can get a relatively robust one. Otherwise I'll see if I can squeeze in a USB mini. Micro is my USB of choice right now because it's the only one that passes the 7-eleven test (available enough that you can buy one 7 days a week, within a few minutes drive of almost anywhere in the country)

 

[Adrian A]

Any word on when the Raven4 will be available Adrian? I want to buy one or two. Would have gone the 3 but nil stock .

In August my day job went from super-busy to pretty much impossible, so I had to put the Raven4 development on the back burner. One of my 3 biggest projects is done for now, so I anticipate being able to start spending at least a little time on the Raven4 again in a few weeks if not sooner. The last I left it, the hardware was all working and the software was mostly-working. That means that realistically it's at least a few months before I'll be shipping.

 

[Adrian A]

Thanks Mike, I skimmed the thread and didn't realise you had already called it out so to speak. I understand Adrian's constraints in terms of not wanting to "reinvent the Raven" but from my understanding the Raven 2 High Altitude firmware eliminates the 0.1 second accuracy of the TVal option and instead gives you the option to configure whole seconds instead. Given the range is from 0 to 51.2 seconds at 0.1 increments that equates to 512 values which does make me consider it to be a board/hardware constraint. But by changing the increments to 1 second that would allow us a configuration range from 0 to 512 seconds. For most high altitude flights 51.2 seconds isn't near enough time from a "time to apogee" perspective. That's what's killing me on the Raven 3 config right now. I'd like to use it as a "pure timer" as you mention but I can't due to the fact that I need to configure a timer value in the range of 90ish seconds. Hence the idea of Baro apogee + 40 second delay.

Also, it seems that accelerometer drift becomes more significant the longer it takes to get to apogee. Given that I believe it's a less than optimal solution to put it mildly given the flight envelope.

The current constraint on the number of possible Tval values came from a pre-FIP need to make the programming values ASCII-compatible. (Sort of like the oft-repeated but apocryphal origin story of train track width, which dates back to Roman chariots) If we make no changes to the FIP for the Raven4, this constraint will stay, but this seems like a relatively low-hanging fruit, so it will go on the short list of things that Kevin and I will consider for FIP updates for the Raven4. It has been about a decade since I worked with that part of the code and I may have forgotten about some other nuance, so don't take this as a promise just yet.

 

[OverTheTop]

In August my day job went from super-busy to pretty much impossible, so I had to put the Raven4 development on the back burner. One of my 3 biggest projects is done for now, so I anticipate being able to start spending at least a little time on the Raven4 again in a few weeks if not sooner. The last I left it, the hardware was all working and the software was mostly-working. That means that realistically it's at least a few months before I'll be shipping.

Thanks Adrian. I can put up with a few months. If it goes much longer I need to find one of the earlier ones second-hand.

 

[curtisheisey]

How about incorporating wifi control in a next generation parrot perch?

The magnetic on/off switch was a great concept, but in actuality, I could never get it to work (and ended up drilling big holes in all my rockets). And with two magnetic switches, forget it, what a nightmare.

I would also like to have terminal blocks for two sets of batteries (altimeter and pyros), and separate switches for both, if there is no wifi control.

(And the first person to market a 2- or 4- channel version of the eggtimer wifi switch is going to make a mint).

 

[manixFan]

How about incorporating wifi control in a next generation parrot perch?

The magnetic on/off switch was a great concept, but in actuality, I could never get it to work (and ended up drilling big holes in all my rockets). And with two magnetic switches, forget it, what a nightmare..<snip>...

At BALLS last week I flew all carbon fiber rockets. I tested them with the Eggtimer wifi and while the thin body tube did allow for some signal to pass, it was quite weak. On the other hand all my rockets used magnetic switches, 2 with redundant altimeters. I typically use a Raven 2 or 3 and a Perfectflite Stratalogger for my dual altimeter flights. The Raven with a Power Perch and the Stratalogger with a magnetic switch. I've never had a problem when using dual magnetic switches. I have several of the wifi egg timer products and see how they are useful but the magnetic switches will work through any type of body tube.


Tony

two altimeter setup with magnetic switches: (fits in a 54mm CF Mongoose clone, flew to 20700' on a CTI L265 at BALLS)