Will do. I expect it’s because the current NOAA file shows kp every minute and it jumps up and down a lot! Kp is meant to be a three-hourly index. . …
Here’s a typical entry:
{"time_tag":"2021-12-01T14:59:00","kp_index":3}
which, according to the current aurora_popup script, is equivalent to an A-index (actually an a-index) of 12:
elseif($kp>=2.9) { $clr3 = $b_clrs['yellow']; $txt3 = number_format($kp*4,0);}
Unfortunately we don’t know if the integer Kp-index was actually 2.67, 3.00 or 3.33, which according to the published conversion table should give a-indexes of 12, 15 or 18 respectively.
The file I am using shows Kp every three hours, e.g.
[["time_tag","Kp","Kp_fraction","a_running","station_count"],...["2021-12-01 06:00:00.000","3","3.33","18","8"],["2021-12-01 09:00:00.000","2","2.33","9","8"],["2021-12-01 12:00:00.000","3","3.00","15","8"]]]
where we can see that the two integer Kp-indexes of 3 were actually 3.33 and 3.00, which are shown to have equivalent a-indexes of 18 and 15. So we don’t even need to calculate the a-index, which is good because the current script conditional look-up table does not agree very well with the conversion table.
So it seems to be a choice between a file that is updated regularly but gives only random snapshot integer values every minute; and a file that gives all the necessary three-hourly information but is often updated hours late. . . 