# Space Radiation Measurement Reliability — project proposal and collaborators **URL:** \ **Category:** AIML AWG Open Projects\ **Created:** [September 26, 2026, 5:08pm UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682 "2026-09-26T17:08:43Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![abhis01](https://avatars.discourse-cdn.com/v4/letter/a/bc79bd/32.png) [@abhis01](https://awg.osdr.space/u/abhis01)\ **Post date:** [October 27, 2026, 11:54pm UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/21 "2026-10-27T23:54:54Z")
Thanks Yeongho! Here’s the [code](https://github.com/abhs21/space-radiation-reliability/blob/4d41d6a5393b38c96f227907618e39201ee364a6/interval_accounting.py), [input intervals and reference results](https://raw.githubusercontent.com/abhs21/space-radiation-reliability/4d41d6a5393b38c96f227907618e39201ee364a6/reports/interval-accounting/results.json), and [report](https://github.com/abhs21/space-radiation-reliability/blob/4d41d6a5393b38c96f227907618e39201ee364a6/reports/interval-accounting/REPORT.md), all at 4d41d6a (the 67-test version). Lets start with these synthetic cases in MATLAB: - Reproduce the report totals: constant and linear **5/9** , adaptive pulse **19/36** , narrow pulse **5/18 microgray**. - Then use a 100 microgray/hour rectangular pulse lasting 10 s, starting at **40, 45 or 50 s** , zero elsewhere on [0,100). Try uniform bins of **5, 10, 20, 50 and 100 s** , starting at zero. - Compare the full [0,100) total and windows ending at **48 and 52 s**. Every full total is **5/18 microgray**. For a window ending at T, truth is 100 × pulse-overlap-seconds / 3600. Use exact bin means: 100 × pulse-overlap-seconds / bin-width. Dose is sum(mean\_rate × duration\_seconds / 3600). For cut bins, label proportional allocation as an assumption and compare it with the true overlap. Could you share your MATLAB script, an error table and a plot? Synthetic data first while the real DosTel intervals are still being checked. ---
**Author:** ![Yeongho\_Lee](https://sea1.discourse-cdn.com/flex001/user_avatar/awg.osdr.space/yeongho_lee/32/5208_2.png) [@Yeongho\_Lee](https://awg.osdr.space/u/Yeongho_Lee)\ **Post date:** [October 28, 2026, 5:50am UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/22 "2026-10-28T05:50:49Z")
Hi Abhi! I’ve completed the initial MATLAB analysis. Thank you for sharing the reference code and results! I reproduced all four reference totals and evaluated the 45 pulse/bin/window combinations. The full [0,100) dose was conserved at 5/18 µGy across all configurations. However, proportional allocation introduced partial-window errors of up to 0.133333 µGy. The error was not necessarily monotonic with bin width, depending on pulse timing and bin boundaries. I’ve uploaded the MATLAB script, error tables, plot, and methodology to GitHub: > **[GitHub - yho0o0/space-radiation-bin-sensitivity: MATLAB reproduction and pulse/bin-width...](https://github.com/yho0o0/space-radiation-bin-sensitivity)** > > MATLAB reproduction and pulse/bin-width sensitivity analysis for radiation dose accounting I’d appreciate your feedback and would be happy to extend the analysis. Please also let me know if you’d prefer future contributions through the project’s existing repository. Thanks again! ---
**Author:** ![abhis01](https://avatars.discourse-cdn.com/v4/letter/a/bc79bd/32.png) [@abhis01](https://awg.osdr.space/u/abhis01)\ **Post date:** [October 31, 2026, 4:50am UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/23 "2026-10-31T04:50:24Z")
Thanks Yeongho! I checked the 45 cases and the totals match. Nice work. One small thing: exportgraphics needs MATLAB R2020a or later. Which version did you use? Your repo is fine for now, we can link the contribution from the project later. ---
**Author:** ![Yeongho\_Lee](https://sea1.discourse-cdn.com/flex001/user_avatar/awg.osdr.space/yeongho_lee/32/5208_2.png) [@Yeongho\_Lee](https://awg.osdr.space/u/Yeongho_Lee)\ **Post date:** [October 31, 2026, 10:25pm UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/24 "2026-10-31T22:25:26Z")
Hi Abhi! Thanks for checking the results! I’m glad all 45 cases match. I used MATLAB R2026a Update 5 for the analysis. You’re right about `exportgraphics` requiring R2020a or later. I’ll update the version requirement in the script and README accordingly. Thanks also for confirming that the GitHub repository works for now. I’d be happy to help with further analysis as the project progresses! ---
**Author:** ![lilmisscupcake](https://sea1.discourse-cdn.com/flex001/user_avatar/awg.osdr.space/lilmisscupcake/32/2889_2.png) [@lilmisscupcake](https://awg.osdr.space/u/lilmisscupcake)\ **Post date:** [November 3, 2026, 11:08am UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/25 "2026-11-03T11:08:25Z")
Hi @abhis01 , @Yeongho_Lee and all, I tested the “long decimal values are means of raw readings” idea on the public snapshots (main, commit 373f801, all 18 files). Method: long rows are on the 5 minute grid with more than 6 decimals (4,244 rows). Raw readings are rows with 6 or fewer decimals. A match means the window mean equals the long value within 2e-9. Results: a window from 150 s before to 150 s after the timestamp reproduces 1,226 of 4,244 long values exactly (29%), mostly as the mean of 3 readings. Windows of 300 s before or after the timestamp give 0 matches. The same centred window shifted by 15 to 50 minutes also gives 0. Among the 58 repeated timestamp groups, 14 have no long value. In 10 of the other 44, the long value matches only when the short reading on the boundary is included. About 71% do not match exactly, with a median difference of 0.8%, so I cannot explain them yet. This is descriptive and does not say which stamp convention is correct. It may help for Kirill’s question about interval start, centre or end for the raw readings. ---
**Author:** ![lilmisscupcake](https://sea1.discourse-cdn.com/flex001/user_avatar/awg.osdr.space/lilmisscupcake/32/2889_2.png) [@lilmisscupcake](https://awg.osdr.space/u/lilmisscupcake)\ **Post date:** [November 11, 2026, 8:16am UTC](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682/26 "2026-11-11T08:16:27Z")
Hi all, a follow up on the timestamp pattern. Using the public snapshots (main, commit 373f801), I tested whether the 5 minute boundary rows are re-aggregated values. A window of 150 s either side of the timestamp reproduces 1,226 of 4,244 long mantissa rows exactly, and shifted windows give none. The number of decimals is not a reliable marker, because a mean rounded to 6 decimals looks short: 647 of 918 lone short boundary rows equal the rounded mean of nearby readings, and in 13 of the 14 duplicate pairs where both values are short, one value equals the mean of the other readings. Filtering by decimals would therefore keep many aggregated values, and dropping all boundary rows is the safe choice. This is descriptive, on public data only. [Previous page](https://awg.osdr.space/t/space-radiation-measurement-reliability-project-proposal-and-collaborators/4682.md?page=1)