Within the US, only Aerojet Rocketdyne AFAIK. And I didn't say there wasn't anyone else, only that ATK clearly has a lot of experience and NASA decided was the only suitable manufacturer (hence the sole source contract.)

If you read the NGIS sole-source procurement (link below) it's for 10 copies of the first and second stage motors and associated TVC. The 10 copies are for 3 demonstration tests, 3 qualification tests, 1 flight test, 1 flight, 1 spare and 1 inert engineering unit.

It doesn't get much realer than that, and there is limited scope for iterative development on the timeline. I can only presume that NGIS (ATK) knows what they're doing; if anyone does, they do.

I share your reservations about the published papers (which are largely high-level parametric "spherical cow" stuff), but in my experience, descriptions of how something will really work rarely get published in advance in the open literature. At least it seems like they are going to cut metal and fly, not just write Powerpoints, and that's always a good sign.

https://beta.sam.gov/opp/349cbd728ab24d7693...true&page=1

On the two-stage solid MAV design, see https://ntrs.nasa.gov/archive/nasa/casi.ntr...20190030430.pdf and https://ntrs.nasa.gov/archive/nasa/casi.ntr...20190002124.pdf

The first stage burns for 55 seconds with a boost-sustain thrust profile.

A two-stage solid rocket to be supplied by Northrop-Grumman has been selected for the MAV.

That seems like the right answer to me. The hybrid was a science project and liquids are just too complicated.

https://spaceflightnow.com/2020/04/20/nasa-...es-off-of-mars/

To anticipate a couple of objections John Whitehead will probably have:

1) the TVC for each stage is not shown. Interesting omission.

2) the launch concept is to "eject vertically from the lander in a horizontal position with the first stage motor ignited within a short interval at a predetermined time following the vertical ejection. In order to navigate the MAV safely away from the lander, this could require sudden, high nozzle vector rates on a motor that has been stored at -40C for up to a year." I guess they decided that simply raising the MAV to vertical prior to launch was more complicated than this maneuver. Well, maybe.

Here's a text file with the predicted position of OREx in the Bennu frame every minute for 24 hours starting at 2020-04-14T00:00:00 (time X Y Z) as extracted from orx_200401_200421_200413_od240-N-TR1D-L-TR1BO_v1.bsp

 tagr.txt ( 103.64K ) Number of downloads: 298

See if https://naif.jpl.nasa.gov/pub/naif/ORX/kern...-L-TR1BO_v1.bsp is what you're looking for.

I think the first letters are the mission phase, for example there was a maneuver R3R (Recon 3R?). Not sure what the second letter means, there have been P, R, D, T. But I could be wrong.

I'm sure this is documented somewhere, but my access to OREx documents is limited and I couldn't tell you if I knew for sure anyway, so I'm just speculating.

I presume you looked at https://naif.jpl.nasa.gov/pub/naif/ORX/kern...-TR1P2-L_v1.bsp

I don't know what the TR1P2 maneuver is (TAG Rehearsal 1 Phasing 2?) but it's small and happened today, and that's the latest file out there. I'd check the mission status update on Monday to see if there are any new tidbits.

I don't know of a public site other than NAIF.

I'm not certain, but I think that's simply an MP4 version of the second GIF animation from the paper, which is just the frames from PJ5.

All of the animations from the paper are at the bottom of the paper in Appendix A. Supplementary data.

Over on nasawatch it's being claimed that the NASA worm logo appeared on the Viking lander, but I couldn't find any evidence of this. Bicentennial logo, yes, Viking patch logo, yes, American flag, yes, but no obvious worm. Maybe there's a small one on the patch? I couldn't find any high-res images of the patch as it appeared on the lander. Anyone know?

For the new readout region, INS-61504_DISTORTION_Y should be 405.48 (the first line of the region changed from 291 to 201.)

Inconveniently, we continue to switch back and forth between the two readout regions (we have to use the old methane setting to take RGB data as it happens because the parameters depend on each other). Typically the old one is used on distant images and the new one only on images close to perijove. For PDS products this will be indicated in the comment for each image somehow, but I'm not sure if this information will show up in the missionjuno metadata.

Sorry for this confusing state of affairs, we didn't anticipate that we might want to change these parameters at all.

Here's some more info about Natural Feature Tracking.

https://www.nasa.gov/feature/goddard/2020/b...hine-as-beacons

Somehow, this blurb completely omits describing the camera being used for NFT or the organization that built it.

As far as I can tell, the plan is still to execute the first TAG rehearsal in April.

At some point we may want a new thread.

I'm not sure what you're wondering about. I think Lori's Glaze's statement is pretty clear that work is continuing on M2020.

I'm not empowered to share details but I can assure you that the statement is accurate.

None of us can predict the future, obviously.

That mission wasn't selected, see the link above.

More info about Janus at https://www.lpi.usra.edu/sbag/meetings/jun2...ns/Hartzell.pdf

There are a variety of public papers and LPSC abstracts about the 2016 incarnation of DAVINCI from which inferences can be made. I'm not free to say anything about what might have changed, sorry.

Could do, maybe, if it gets selected and if the massive complication of removing atmospheric signature actually works.

But perhaps I'm biased.

The 1 msec is simply a fixed command offset we forgot to account for.

The clock oscillator that is commanding the frames is advertised as being +/- 150 PPM over its entire temperature range and radiation dose. So changing the typical interframe of 370 msec by more than about 55 microseconds would mean the oscillator is not performing to specifications. Which is certainly possible, but I would expect some systematics we're not seeing were it the case.

We are in the process of releasing revised START_TIMES to the PDS based on manual measurement of the first limb crossing. There could be many explanations of what might cause mismatches at the last limb crossing (interframe off, spin axis or rate knowledge off, speed of light not being properly accounted for, deviation of limb from spheroid, etc.) My goal has merely been to get to the point where the community can use ISIS3 without seeing unacceptably large inconsistencies, and I think we've achieved that.

It is an uncontrolled point perspective projection only intended as an unofficial pretty picture and not archived with PDS.

Did the lander footpads do anything unusual? Sol 10 and 14 images of the footpads look fairly normal.

Insight's IDS is in fact the MSP 01 lander's, refurbished: http://esmats.eu/esmatspapers/pastpapers/p.../fleischner.pdf

Phoenix used a modified version of this arm (if they could have used the original one, I assume they would have) but I wasn't able to find a good description of the differences.
https://www-robotics.jpl.nasa.gov/publicati...itz/f1695_2.pdf

Most of the differences may be in the scoop.

If you look very closely you can see a steady increase in warmish pixels, but nothing that affects imaging to any significant degree. At least that's what I would say, all of the images are available for anyone to examine -- we take a dedicated radiation monitoring image at the end of each pass to look for changes.

Certainly you can see a lot of transient particle hits in parts of the orbit, some orbits more than others.

As the orbit evolves the spacecraft will get more radiation dose per perijove, but so far so good.

We're keeping that one secret because of the big conspiracy, but you caught us.

Seriously, it still has a data gap that hasn't been filled in by DSN replays.

Don't hold your breath. "Success has a thousand parents but failure is an orphan." And they already documented the useful lessons learned.

Rather a lot. Even at 1 AU not enough energy lands on the CCD to damage it thermally. If you tried to image with the sun near the center of the detector, there is an electronic effect that could damage the sensor; see https://www.onsemi.com/pub/Collateral/AND9183-D.PDF for details. You may recall that there was an orbit with an unusual orientation that Junocam didn't image for, this was the reason.

I haven't looked at the temperature data but I don't expect anything significant.

http://emits.sso.esa.int/emits-doc/ESTEC/A...l-Functions.pdf

It's not a big mystery, it was just human error, no doubt exacerbated by the complex cross-organizational, international nature of the mission and the fact that the commanding was somewhat arcane and error-prone.