Over tijd en waarnemingen

Overlegtafels Calibratie Over tijd en waarnemingen

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #863

    P_Biemans
    Participant

    Beste mensen,
    Ik ben nu enige tijd bezig met uit te zoeken hoe de gegenereerde data van dit project in elkaar zitten, wat ze voorstellen en hoe ik ze moet interpreteren. Ik doe dat als burger-deelnemer aan dit project. En ik probeer me hierbij ook voor te stellen hoe andere niet-technische burgers, van wie ik er ook een ben, met al die data om kunnen gaan.
    Wat valt mij dan op. Allereerst de tijd zelf en de tijdseenheid waarmee gewerkt wordt in dit project. Het blijkt, als ik het juist heb, dat de tijdbasis niet in overeenstemming is met de officiële tijd, de cesium-atoomklok van het Rijksinstituut voor Techniek en Natuurkunde te Braunschweig. Die tijd wordt gecodeerd verzonden vanuit Mainflingen (Frankfurt). Stel zowel bij de SmartApp alsook bij de Whale.citygis de tijd af op de Frankfurttijd, is mijn verzoek. Er zit in de tijd van dit project een verschil van ongeveer 2 minuten, vóór de tijd uit lopend, met een zeker variatie. Dan stel ik voor om bij dit burgerproject alleen maar te werken met de Nederlandse tijd en niet ook met de “Days en Hours in UTC”. Want in whale.citygis krijg je dan bij “properties” wel weer te maken met een andere aangebrachte tijd. Laten we het voor de burger eenduidig en simpel houden. Dan: bij de whale.citygis krijgen we een automatische verversing van nieuwe meetwaarden door met een aangepaste tijd om de 10-11 seconden. Prima. Zo zou het moeten zijn. Maar bij de SmartApp gebeurt die automatische verversing niet automatisch, wel bij het opnieuw aanklikken van het station na verloop van tijd van ongeveer 3 minuten. De bijbehorende tijd klopt dan vaak ook weer niet. Ook daar moet een oplossing voor komen.
    Iets anders. De variabele “geluid” zit zowel in de SmartApp alsook onder de Whale.citygis onder “sound”. In de SmartApp wordt geluid gegeven in dB(A) en in het niveau van 1-5. In de Whale.citygis onder sound krijg je geluid mooi gepresenteerd met een grafiek bestand uit dB(A)-niveau met de variatie aan Hz, dus een combi grafiek. Een prachtig mooi plaatje! Maar: Ik kan in History geen data krijgen van de dB(A) door de tijd heen omdat die er niet inzit. Die zou er zeker ingebracht moeten worden, zodat door de tijd heen in History ook de geluidsdata dB(A)opgevraagd kunnen worden. Dat betekent dat geluid/ sound in de Whale.citygis integraal als de andere grootheden ook opgenomen zou moeten worden.
    Dan zou er op schrift duidelijkheid moeten komen wat de waarden door de tijd heen gemeten in tijdseenheden precies voorstellen. Welke gemiddelden-waarden ze precies voorstellen. Zijn het voortschrijdend gemiddelden of iets anders. Voor mij is dat niet duidelijk.
    Mijn bovenstaand verhaal vloeit voort uit een poging mijn sensor: 58 in geluid te kalibreren(?). Ik heb daarvoor van Peter van der Voorn van de gemeente Nijmegen een precisie-instrument gekregen en ik heb op dinsdag 29 november van 12-13 uur (Nederlandse tijd) een uur lang het geluid opgenomen omdat er geen andere mogelijkheid is om eventueel te vergelijken. Ik hoop dat ik het goed gedaan heb en maandag a.s. zal dat bij Peter van der Voorn hopelijk blijken. Het ontvangen precisie-instrument gaf na precies één uur gemeten te hebben cumulatief een waarde aan van 58.0 dB(A). We moeten even nagaan met welke waarde uit ons project dat vergeleken kan worden. Ik stuur nog een foto van de opstelling.

    Met vriendelijke groet,

    Piet Biemans

    #864

    P_Biemans
    Participant

    Hierbij enige foto’s.

    Attachments:
    1. IMG_9443

      IMG_9443.jpg

    2. IMG_9439

      IMG_9439.jpg

    3. IMG_9439

      IMG_9439.jpg

    #867

    P_Biemans
    Participant

    Wat ik nog vergeten was te vertellen. In het college van Peter van der Voorn is gezegd dat voor een goede opstelling van een sensor om het geluid te meten een afstand van tenminste 1.5 m vereist is om tot geldige metingen te komen. In mij situatie is dat duidelijk niet het geval. Ik wil ter zijner tijd wel aan die eis voldoen en dat betekent dat een andere opstelling gezocht moet worden. Mijn vraag aan de sensoropstellers is om daar medewerking aan te verlenen. Maar dat komt later wel.

    #870

    L. Carton
    Keymaster

    Piet,

    Over de tijd aanduiding: Ik weet nog dat de ruwe data de uurwaarden in een ander tijdsysteem weergaf, met een uur verschil. Daar is voor gecorrigeerd in het ETL-proces. Het ijken van de klok en tijdstippen vergt kijken naar het ETL-proces dat de data verwerkt.

    De Whale viewer toont de huidige ruwe meetdata (“current values”) en niet de historische data. De Whale viewer is gemaakt voor technische doeleinden en zou oorspronkelijk niet gebruikt worden, maar uit oogpunt van transparantie en ook de ruwe data beschikbaar te stellen, is die ‘ruwe data viewer’ ook ingebracht als optie om te bekijken. De tijd die daar getoond wordt is wellicht de ‘timestamp’ zoals het sensorstation die doorgeeft, in de betreffende datum-tijd-weergave. In de Whale viewer wordt momenteel geen efforts gestoken om daarvan een geavanceerdere vieuwer/portal van te maken.
    De Smartapp kan inderdaad een vertraging vertonen in de weergave van data. De Whale viewer, die op de ruwe datastroom geplugd is (op de 1e server die de sensordata ontvangt), heeft dat niet.
    De historische data, die je kunt zien op de Heron viewer, wordt nu opgeslagen in de vorm van uurgemiddelden, mede om de hoeveelheid data en de benodigde groeiende server-ruimte binnen de perken te houden.
    Eventueel kunnen Just (Geonovum) en/of Robbert (CityGIS) hier een aanvullende reactie plaatsen?
    Just en Robbert, jullie hebben destijds naar de tijdsweergave gekeken, toen de API van CityGIS en het ETL proces van Just op elkaar werden afgestemd. Kunnen jullie de vraag van Piet beantwoorden over de tijdsynchronisatie tussen de Jose-sensor, de ruwe data (op de Whale viewer afgelezen door Piet) en de weergave op de SmartApp ?

    Ik heb even op Github gekeken in de code over de verwerkingsslagen in het ETL proces. Alhoewel ik geen programmeur ben en python niet kan lezen, denk ik op te kunnen maken dat de time-in-UTC wordt gehanteerd (referentie naar “current day and hour in UTC” in https://github.com/Geonovum/smartemission/blob/master/etl/rawsensorapi.py)

    Piet, hieronder een stukje over de open source code beschrijving van Just:

    Van: https://github.com/Geonovum/smartemission/blob/master/etl/rawsensorapi.py
    Code:
    1 # -*- coding: utf-8 -*-
    2 #
    3 # RawSensorInput: fetch raw values from CityGIS Raw Sensor REST API.
    4 #
    5 # Author:Just van den Broecke
    6
    7 import json
    8 import time
    9 from datetime import datetime, timedelta
    […]
    20 class RawSensorAPIInput(HttpInput):
    21 “””
    22 Raw Sensor REST API (CityGIS) Base Class to fetch observations for devices.
    23 “””
    […]
    542 def get_current_day_hour(self):
    543 # Get the current day and hour in UTC
    544 current_time = time.gmtime()
    545 current_day = int(time.strftime(‘%Y%m%d’, current_time))
    546 current_hour = int(time.strftime(‘%H’,current_time))
    547 return current_day, current_hour
    […]
    565 # Get the current day and hour in UTC
    566 current_day, current_hour = self.get_current_day_hour()
    […]
    593 # Create a data record for timeseries of current device/day/hour
    594 def format_data(self, data):
    595
    […]
    596 #
    597 # — Map this to
    598 # CREATE TABLE smartem_raw.timeseries (
    599 # gid serial,
    600 # unique_id character varying (16),
    601 # insert_time timestamp with time zone default current_timestamp,
    602 # device_id integer,
    603 # day integer,
    604 # hour integer,
    605 # data json,
    606 # complete boolean default false,
    607 # PRIMARY KEY (gid)
    608 # );
    —einde code—-
    Groet, Linda.

    #872

    B_d_Greef
    Keymaster

    Hoi Piet,
    Terugkomend op de geluidsdata: ik zou de data downloaden met de Heron viewer; de handleiding daarvoor staat ook op dit forum: http://smartemission.ruhosting.nl/forums/topic/handleiding-om-sensor-data-te-downloaden/

    Ben benieuwd naar de resultaten!

    #874

    P_Biemans
    Participant

    Nu, zeg het zelf maar. Is het volgens de sensor 45 of 49? Ik ben ook benieuwd.
    De meting vond gedurende een uur plaats op dinsdag 29 november tussen exact 12.00 en 13.00 (Nederlandse tijd).

    #875

    B_d_Greef
    Keymaster

    Ik begrijp de vraag niet?

    De decibelwaarde staat toch in de data?

    #955

    Hallo Bas.
    Er is een aparte microfoon naast de sensor geplaatst. Deze is geijkt en aangesloten op een geijkte SLM (sound level meter). Gedurende het door Piet aangegeven uur is er een energetisch gemiddelde bepaald die sterk afwijkt van de waarde uit de sensor.
    Er kunnen verschillende oorzaken zijn.
    1) Meten we in dezelfde tijd? De afwijking bij een uur metn zal gering zijn bij enkele mnuten afwijking.
    2) Wordt de waarde goed berekend? Wordt het energetisch gemiddelde bepaald? Over welke tijdspanne?
    3) Geeft de geluidssensor de juiste waarde?
    4) Is er correct gemeten met de geijkte meter? Ja!

    #956

    De resultaten van de meting met geijkte apparatuur.
    De gemelde tijd is de starttijd van de meting. Lokale tijd.
    Gemeten equivalent gemiddeld geluidsnivo over één uur is LAeq is 58 dB(A).

    ———————-
    Bruel & Kjaer
    SLM Type 2236

    SETTINGS:
    ————————
    F 30-110 dB
    RMS: A Peak: L

    RECORD NO,:
    ————————
    29 Nov 2016 11:59:47
    Elapsed Time 0001:00:07
    Pauses 0
    Overload 0,0 %

    MaxP 94,7 dB
    MaxL 76,6 dB
    MinL 39,5 dB

    Leq 58,0 dB
    SEL 93,5 dB
    LEPd (Te= 7h30) 57,7 dB

    L1 67,0 dB
    L10 62,5 dB
    L95 44,0 dB

    #957

    P_Biemans
    Participant

    Voor de goede orde. Ikzelf heb het resultaat van waarde van 58,0 dB van de geijkte apparatuur vergeleken met de waarde 49 dB uit de HeronViewer.

    #958

    En met de Smart App?

    #970

    29 november 2016 tussen 12.00 en 13.00 uur.
    Positie geijkte geluidsmeter exact naast de (jose) sensor 58. Zie foto’s van 30 november in deze topic.
    De geijkte geluidsmeter geeft 58 dB(A) aan. Dit is een equivalent gemiddelde over één uur tussen 12.00 en 13.00 uur.
    De Heron Viewer 49 dB(A).
    En de Smart App
    12:02 uur 42 dB(A)
    12:14 uur 44 dB(A)
    12:32 uur 57 dB(A)
    12:45 uur 40 dB(A)
    13:02 uur 54 dB(A)

    #983

    B_d_Greef
    Keymaster

    Ik denk dat dat te maken heeft met de vertraging tussen de servers. De Whale server is het eerste station en daarom het snelst, de apps draaien op een andere server.

    #1020

    P_Biemans
    Participant

    Beste Peter,

    Kun jij morgen vertellen wat uit de ijking en de vergelijking gekomen is? Het resultaat is voor mij nog steeds onduidelijk.

    Met groet en tot morgen,

    Piet

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.