High rad values in API viewer DON'T match LOG or KML files

[Eri Nakamura]

HI everyone! 

I'm trying to get some help with this issue, and am posting in every safecast forum in the hopes that I get a response.  We are having a big problem with our safecast data, which I believe has to do with Coding.  If anyone is able to help us figure out the conversation tool, we cna probably do the conversions ourselves.  But so far no one at Safecast has been able to help us - hoping someone here will! Thanks!

I’m reaching out with some questions about how bGeigie Nano LOG data correlates with how the data is fed through the “Viewer” as displayed in Safecast’s API, and then how this is filtered in the KML file output. 

 According to our calculations, the bGeigies calculate uSV rates by dividing each CPM value by 333.3333333, to render the correct uSV value.  (Typically a Geiger-Muller tube would calculate the uSV in this way:  uSv/h and CPM: 0.0057 * CPM = uSv/h  AND 1CPM = 12*CP5.  But bGeigies seem to be dividing by 333.33333, as above.)  

However, when we look at the LOG files as raw data (imported into "R" software) or when we download the LOG files from the API in KML format, any dose counts (readings) higher than 150CPM have been dropped from the file arbitrarily.  And yet, we can see them in the OLED display when we are taking the reading *and* we can see them in the Safecast API Viewer app online.  I don't think this is the first time this has happened - other users must also have this problem - can someone please help us resolve this issue?

 Previously, I wrote Safecast Device Discussions and Support, and asked why “high radiation values would disappear from the KML files after the .LOG files had been uploaded to the API.   When the log files are uploaded to the API and then downloaded as KML files, we seem to lose all uSv/h and CPM values above 150 CPM.  Our question for you is - Is this a programming error or glitch in the upload mechanism, or, other?  *Given Safecast's mandate to empower citizens with knowledge of radiation levels, I am surprised that others have not pointed out this problem before, as it is a serious issue.

Thanks for reading! - Eri 

***March 29, 2020: one safecast maintainer explained:  

Pretty sure what's happening here is that the viewer has special code that will swap in the cpm5s at cpm values over 100: https://github.com/Safecast/Tilemap/blob/master/bgeigie_viewer_worker.js#L338-L343

But the kml export doesn't have any special handling https://github.com/Safecast/safecastapi/blob/master/app/views/bgeigie_imports/bgeigie_logs.kml.erb#L166-L167

 We could potentially have the `usv` function implement similar logic https://github.com/Safecast/safecastapi/blob/master/app/models/bgeigie_log.rb#L22, maybe (the staff person in charge of coding the viewer) would be good to comment on if that's a good idea or not since he implemented the viewer logic.”

Also -

I think at this stage it's more a question for the other maintainers on if we have the ability to do the same swap to cp5s.

 

For now just understand that the KML contains _only_ the CPM and the µSv is calculated from that.

 

The viewer on api.safecast.org is a little fancier and will use the cp5s to calculate the µSv under certain conditions. This often makes the map show a somewhat higher calculated dose rate.

 

If you needed something very short term, we could add the cp5s to the kml alongside the CPM I think but from looking at the format I doubt it'd be very useful.