PDS_VERSION_ID = PDS3 DATA_SET_ID = "JNO-J/SW-JAD-5-CALIBRATED-V1.0" RECORD_TYPE = STREAM OBJECT = TEXT PUBLICATION_DATE = 2024-09-24 NOTE = "ERRATA.TXT reflects any known deficiencies with files contained on volume JNOJAD_5001." END_OBJECT = TEXT END ERRATA This file contains a list of all deficiencies and irregularities that are known to exist at the time of the publication date above. Any errors detected with this volume will be published on subsequent volumes in this volume set. ------------------------------------------------------------------------------ [Added 2024-Jul-18] For Version 01 files up to 2023-327 (PJ56 + 1 day) the DESPUN_SC_TO_J2000 and SC_VEL_ANGULAR_J2000XYZ objects have inaccurate records occasionally, roughly one record affected per day (but occasionally more) per data product. This has been fixed in files from 2023-328 and onward, and for any future Versions, but remains in previous files. The issue was introduced in the JADE Level 3 Version 04 files, DATA_SET_ID of JNO-J/SW-JAD-3-CALIBRATED-V1.0, used as input to make the Level 5 Version 1 files here, and has simply filtered through. The explanation, taken from the Level 3 ERRATA.TXT file, is as follows: DESPUN_SC_TO_J2000 is a critical transformation matrix if you want to convert from the despun spacecraft coordinates to J2000, then on the JSS, e.g. for moments calculations or pitch angles. The issue was a tolerance setting in the SPICE command ckgpav (which returns both the DESPUN_SC_TO_J2000 and SC_VEL_ANGULAR_J2000XYZ values). From previous missions, we set a tolerance, and had been set to the equivalent of one Juno spin (30s). However Juno has continuous ck kernels and we should have set the tolerance to zero (and now have for all data since 2023-328). Practically this should make no difference, we ask for a time and the ckgpav command is expected to return the values exactly at that time due to the continuous ck kernels. And this is usually what happens. In the SPICE ckgpav documentation we found the warning: "In general, because using a non-zero tolerance affects selection of the segment from which the data is obtained, users are strongly discouraged from using a non-zero tolerance when reading CKs with continuous data." It seems that if the time we request is near a segment boundary (in the CK file) to within the non-zero tolerance, it can return values within the tolerance, but not at the exact time we asked, essentially flat-lining the output for the duration of the tolerance (30s in our case). i.e. despite Juno spinning, the returned output would fix the orientation for 30s. This was found from numerical moments for an hour that were of corotating plasma, but one moment was anticorotational, despite the plasma clearly being stable for the whole period. While the moments in the spacecraft frame were consistent for all, it was realized one record had a drastically different DESPUN_SC_TO_J2000 matrix than all its neighbors, thus this incorrect orientation implied an anticorotational flow. For an example, see the record at 2017-038T07:32:11.857 in file JAD_L50_LRS_ION_ANY_DEF_2017038_V01.DAT ------------------------------------------------------------------------------