Next-Gen Raven Development Thread

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
..Aaaand making the red and blue LEDs correspond to low beeps and high beeps is done. So now you can see the 4-channel continuity status (blue is connected, red is not connected), and you can also watch the altitude readout (blue counts the non-zero decimal places, red shows the zero decimal places). I should have done this a long time ago.
 
Wow, that's exciting news, good to hear.

To clarify on the LEDs, in post 90 you have a picture of the PC board with holes for what looks like pass-through LED mounts. Is that correct? So does that mean we could make a wiring harness for remote LEDs? And also that you've programmed the LEDs so that while in pre-launch phase blue flashes mean channel continuity and red means open?

Thanks,


Tony
 
Wow, that's exciting news, good to hear.

To clarify on the LEDs, in post 90 you have a picture of the PC board with holes for what looks like pass-through LED mounts. Is that correct? So does that mean we could make a wiring harness for remote LEDs? And also that you've programmed the LEDs so that while in pre-launch phase blue flashes mean channel continuity and red means open?

Thanks,


Tony

Yes, both are correct. To dive a little more into the details, the solder pads for external LEDs are in parallel with the existing LEDs, so they will share current with them depending on how their forward voltage drop compares with that of the existing LEDs. The total LED current is controlled so you needn't be concerned about over-driving any LED.

Whenever the low beeps and high beeps are used, the blue LED lights up during a high-tone beep and the red LED lights up during the low beep. So yes, during prelaunch the blue/red LEDs represent connected/disconnected channels respectively. Also, during altitude beep-out after the flight, zeros digits are represented by single flashes of the red LEDs while the non-zero digits are represented by counting flashes of the blue LED.
 
The first units are back from the assembler. I tested one and it works fine. Next up is programming and testing. We're working out the schedule for that. I may be able to start shipping next week, or otherwise the week after that. I'll get the website updated.

Last week I remembered another request that was made long time ago on a thread about magnetic switches, and that is to provide audible feedback earlier in the boot-up process. So today I changed the code to add a low-tone beep right at power up, followed by a pause for the voltage to stabilize before the voltage beep-out takes place.
 
The first units are back from the assembler. I tested one and it works fine. Next up is programming and testing. We're working out the schedule for that. I may be able to start shipping next week, or otherwise the week after that. I'll get the website updated.

Last week I remembered another request that was made long time ago on a thread about magnetic switches, and that is to provide audible feedback earlier in the boot-up process. So today I changed the code to add a low-tone beep right at power up, followed by a pause for the voltage to stabilize before the voltage beep-out takes place.
Great to hear about the progress. And the immediate tone after power-up will be greatly appreciated. The delay to hear the beeps sometimes lead me to power cycle unnecessarily. Fortunately my wife is always happy when I buy my own Christmas gifts, makes her life a lot easier.


Tony
 
The first units are back from the assembler. I tested one and it works fine. Next up is programming and testing. We're working out the schedule for that. I may be able to start shipping next week, or otherwise the week after that. I'll get the website updated.

Last week I remembered another request that was made long time ago on a thread about magnetic switches, and that is to provide audible feedback earlier in the boot-up process. So today I changed the code to add a low-tone beep right at power up, followed by a pause for the voltage to stabilize before the voltage beep-out takes place.

Any update info? I noticed that the web site has Raven 4 pics and a list of specs/features but no way to order or a potential release date.

Inquiring minds ...
NikeMikey
 
I'm about to open up orders for the Raven4, though with the caveat that the units won't ship until the end of next week. I have some new quick start cards on their way from the printer, which can be used as a drill template. I have attached a .pdf if any of you want to start using it before then.
 

Attachments

  • quick start 2019Jan16_cent.pdf
    1.6 MB · Views: 94
Thanks for that, I am designing some 3D printable altimeter mounts and it's good to have the new dimensions. Looking forward to seeing one in person.


Tony
 
Flights from Raven4 production units are showing good results from the Raven4's new accelerometer. We'll want to collect data from more flights before passing final judgement, but it's looking like the Raven's long-standing issue of accelerometer accuracy is in the past. The following data came from Kevin Small's flight from a couple of weeks ago, using 10Hz GPS recorded data, which is a feature of the Featherweight GPS Trackers we are working on that is almost complete.

upload_2019-4-26_10-56-18.png


The difference between the accelerometer-based apogee altitude and the GPS AGL altitude was 1%, closer even closer than the baro-based altitude, which is about 2% low, due to flying in warmer conditions than the standard atmosphere model assumes.

The results were also good news for the GPS performance. The Featherweight GPS tracker only logs GPS points to the file when they pass the GPS receiver validity checks, so all of the points you see in the graph are valid data. 96% of the possible GPS measurements were valid in this flight. The graph below shows that the new U-Blox 8th-generation receivers are great at velocity measurement as well:

upload_2019-4-26_11-10-25.png


There is excellent agreement between the acclerometer-derived velocity and the GPS velocity. The GPS provides the velocity in 3 dimensions relative to the ground, while the accelerometer only knows what the velocity is in the direction of the rocket, wherever it's pointing (assumed upward until apogee). This is potentially a big advantage for using GPS for measuring velocity, since it also can be used to calculate the flight angle, as shown above. You can see that during the boost the flight angle was around 3 degrees, and stayed under 10 degrees until 16 seconds into the flight. At apogee, the flight angle is 90 degrees (by definition) At some point I'm going to make a combined GPS tracker/altimeter that uses the GPS-based flight angle as a safety check for airstarts.
 
With the GPS validity checks, not sure if you’re talking about the RX r TX. However, while it’s good not to include any invalid data in graphs etc, I would recommend logging all data received by the RX. If there is difficulty locating the rocket, a partial GPS sentence may be enough to locate the rocket. This of course relies on the operator manually going through the log and figuring out what they are looking at etc.

Note that I have seen google earth do some weird stuff with bad sentences. One of my rockets apparently took a detour to the Atlantic Ocean, off the coast of Africa. I was launching from Australia.
 
Back
Top