SAFECAST API support for LOG files from bGeigie equivalent device

[Jan Helebrant]

Hi,

with our increasing “fleet” of bGeigies (over 50 now and got a few more now) we are also facing complicated technical maintenance - replacing damaged or faulty parts etc. Buying anything outside the EU is really annoying because of some formal requirements (for institutions) / customs etc. so we wanted to be more flexible. The US shipping prices significantly increase the final price of the device and we also had to order bGeigies without batteries (to buy them later here) because air transport limits the number of Li-Ion batteries in one package :-(

So about 1.5 year we started a development of a device called CzechRad which would fit in the same Pelican case and would solve most of our problems + also improving some features of bGeigie. Also changing the approach from buying modules from the US market to ordering basic electronic components from major EU distributors and producing the boards here. This reduces non-EU shopping to the detector unit only.

As development continues, we also wanted to test compatibility with the Safecast API. Our LOGs work nice with the Safecast QGIS plugin but our import here:

https://api.safecast.org/en-US/bgeigie_imports/49022

was not processed correctly and although the map displays all the data points and shows 0 measurements. I discussed this with Mat and he finally recommended me to bring the discussion here. 

Jan

Details about CzechRad

Main differences from bGeigie Nano:
- one mainboard replaces Fio, OpenLog and GPS module
- detector board replaces iRover
- brand new firmware but same LOG format to keep compatibility

Main board

- OpenHardware design (will be published)

- SAMD21G processor (ARM M0+) by Atmel / MicroChip
- MAX1811 charging circuit by Maxim Integrated - at least 2 times quicker charging than bGeigie
- GPS module by uBlox - NEO-M8 series with concurrent reception of up to 3 GNSS (GPS, Galileo, GLONASS, BeiDou) - testing confirmed quicker position fix, possibly better sensitivity and precision
- built-in full-sized SD card slot

- miniUSB for charging and data comm.

Display

- monochromatic graphic LCD module - better readable even in direct sunlight

prototype photo (displayed content to be changed…)

Detector board
- High Voltage power supply module by EMCO / XP Power instead of iRover
- buzzer, LEDs

Firmware:
- own code to implement the different design and components
- put the device configuration and number „inside“ and not on the SD card so the user cannot accidentally delete them

Format
- keep the LOG data format to manage 100% compatibility with SAFECAST API, Tile Map and QGIS Safecast plugin
- we wanted to introduce different device model to avoid conflicts with bGeigie imports and also make possible to distinguish these device in the DB

- format looks this way:

# NEW LOG
# format=2.0.0CzechRad
# deadtime=on
$CZRDD,1000,2020-08-30T16:54:53Z,42,5,769,A,4955.9707,N,01430.9641,E,369.53,A,8,110*6B
$CZRDD,1000,2020-08-30T16:54:58Z,40,1,770,A,4955.9712,N,01430.9652,E,368.74,A,8,110*6C
$CZRDD,1000,2020-08-30T16:55:03Z,38,2,772,A,4955.9707,N,01430.9659,E,366.19,A,8,110*67
$CZRDD,1000,2020-08-30T16:55:09Z,37,2,774,A,4955.9688,N,01430.9722,E,361.33,A,8,110*60
$CZRDD,1000,2020-08-30T16:55:14Z,38,6,780,A,4955.9692,N,01430.9784,E,361.47,A,8,110*68

Communication
- currently no Bluetooth implemented, could be added in future
- usb communication going to be implemented - for bulk data download, device maintenance and updates
- real-time data sending via cable (virtual COM over USB) possible

PS: before official deployment in the field the device will undergo testing in the X-ray and gamma ray laboratory - see the description here:

https://www.suro.cz/en/suro/vybaveni

[Rob Oudendijk]

Jan,

At Safecast we have been discussing how to deal with non-standard bGiegieNano formatted drives. there are too many differences between the units to directly import them into our database. If you could send the data in a JSON string and have the files proper marked that would maybe be a better option. Also, the tracking of the device's owners for the bGiegieNano are done manually by Safecast staff. Are you willing to support the same for the new devices?

regards,

rob

[Rob Oudendijk]

Jan,

Maybe  Edouard Lafargue (maker of the Safecast app for Android) has some ideas to how to import the measurement into the database with a JSON format with more details about the device. Or maybe we could use the second line of the measurements as a way to add more information about the measurement as I did before in a Rakuten bGiegie based air quality sensors for bikes. That project used the standard bGeigeiNano tube, so need for changing the format there. (Eyes Japan project). 

Second line format I used was like :

$BNXSTS,2030,27,47,511,0.000,109,34,5-3

header, ID,temperature, humidity, CO,NOX, NH3, PPM25, UV, pollen

regards,

rob

[Jan Helebrant]

Dear Rob,

At Safecast we have been discussing how to deal with non-standard bGiegieNano formatted drives. there are too many differences between the units to directly import them into our database

this is why I am asking because we should be able to adjust the LOG format to be as standard as possible. We could probably make our LOG be the same as those from bGeigie and the API would probably notice anything wrong but there would be later conflicts because of the device numbers as there would be sooner or later some Kithub produced bGeigie with the same number... So we thought it is fair to mark these devices differently to avoid this.

Also, the tracking of the device's owners for the bGiegieNano are done manually by Safecast staff. Are you willing to support the same for the new devices?

I am curious about this. How do you manage this? Because major part of our bGeigies (all managed by user with ID 671) were bought through 3rd party distributor in Europe. Anyway, the CzechRad devices are currently planned to be managed within the same account .

If you could send the data in a JSON string and have the files proper marked that would maybe be a better option.

Does this mean we should have to develop some uploader tool to somehow log in your DB and upload the measurements from the LOG files? Because the QGIS LOG processing is essential part of our workflow.

regards

Jan

Dne sobota 12. září 2020 7:40:58 UTC+2 Rob Oudendijk napsal(a):