algoritme om events aan elkaar te koppelen

[WVL_KsZeN]

Ik ben bezig met een klusje waarbij ik de verschiltijd tussen een events wil bepalen. Ik krijg van twee detectoren een pulsje binnen als er iets gebeurt, het pulsje van de tweede detector komt later dan dat van de eerste. Nu ik wil proberen beide pulsjes aan elkaar te 'koppelen', zodat ik de verschiltijd kan uitrekenen en een grafiekje kan maken van de gemeten verschiltijden.

Een plaatje van de data zoals ik deze in mijn C# programma heb is misschien handiger :-)



Ik heb een pijltje getekend tussen pulsjes die bij elkaar horen, te zien is dat de tijd tussen de pulsjes varieert (hier 3.7, 3.9 en 4.9 seconde).

Nu vind ik het lastig om een goed algoritme te bedenken om uit te vogelen welke pulsjes nu bij elkaar horen. De eerste set pulsjes bij 10:02:10 is makkelijk, maar in het deel van 10:02:20 tot 10:02:30 is het een stuk lastiger.

Mijn eerste gedachte is om de 2e tijdsbalk op te schuiven in de tijd met de gemiddelde tijd tussen pulsjes, het is dan makkelijker te zien welke bij elkaar horen. (voorbeeldje heb ik in Paint gemaakt).


Een lastig punt is dat de pulsjes soms niet helemaal netjes zijn en je een dubbel pulsje op de ene detector hebt en slechts één pulsje op de andere detector. Of andersom : wel een pulsje op de ene detector, maar niets op de andere. Het is dus niet zo dat pulsje nummer X op detector 1 altijd gekoppeld is aan pulsje nummer X op detector 2...

Kan iemand mij een paar goede zoektermen geven? of de naam van een algoritme? Ik weet niet goed waar ik op moet zoeken..

Mijn gedachte is nu zo :

- koppel pulsje X van detector 1 aan pulsje X van detector 2
- in een loopje :
- bepaal de verschiltijd van alle koppeltjes en controleer op gekke dingen (extreme afwijking, dwz < 3s of > 6s).
- bij een afwijking < 3, koppel dan vanaf hier pulsje X van detector 1 aan pulsje X+1 van detector 2 (maak de tijd groter)
- bij een afwijking > 6s, gooi dan pulsje X van detector 1 weg, en koppel pulsje X+1 van detector 1 aan pulsje X van detector 2.

of...

Een andere optie zou zijn om van _alle_ mogelijke koppels de verschiltijden te bepalen en daar alle onrealistische koppeltjes uit te filteren. Je houdt dan een kleine subset van koppels over. Hier zitten vast een paar dubbele tussen (detector in meerdere koppeltjes), die je er dan nog uit moet filteren..

Maar ik mis vast nog iets slims...

[P_Tingen]

Hoeveel van die pulsen heb je? Is dit een continuestroom van pulsen of is het te overzien wat je binnenkrijgt? Als dat laatste het geval is en je hebt hooguit een paar honderd of paar duizend pulscombinaties zou je kunnen proberen de 2e tijdsbalk zo te verschuiven dat de gemiddelde afwijking tussen alle bij elkaar horende pulsen zo klein mogelijk is (en 'bij elkaar horend' zou je dan kunnen definieren als ergens tussen 3 en 6 seconden). Weesjes die geen partner hebben negeer je dan verder, wat je algoritme een stuk overzichtelijker maakt.

[CH4OS]

Kun je de pulsjes niet aanpassen? Dat ze voor zichzelf de timer eerst starten en daarna pauzeren of stoppen? Zo hou je voor jezelf ook een beter overzicht denk ik, om welk pulsje het precies gaat. Ook is het wisselen van pulsjes / detectoren dan wat makkelijker. Anders moet je ook steeds de combinaties gaan bijhouden of aanpassen. Als je een historie / archief bijhoudt, veranderd daar ook niets aan, anders zul je ook de combinaties moeten archiveren.

[ Voor 21% gewijzigd door CH4OS op 22-01-2016 12:21 ]

[pedorus]

Ik zou ook een minimale en maximale tijd definiëren voor de tussentijd, dus zeg 3-6 sec. Je zet alles van balkje 1 in een queue met tijdstip. Dan ga je balkje 2 af, en per pulsje proberen te matchen met de queue. Is het voorste pulsje voorbij de max-tijd, dan ontbrak er een pulsje op balkje 2 of was er een dubbele op balkje 1, en verwijder je de voorste (net zolang tot niet meer zo). Zit je onder de min-tijd, of is er geen element meer in de queue, dan ontbrak er een pulsje op balkje 1, of heb je een dubbele op balkje 2, en dan haal je geen element uit de queue. In het derde geval, als het ertussenin zit, dan heb je een match. Zo ga je alles af, en heb je matchende tijden, en twee tellingen voor ontbrekenden/dubbelen.

Natuurlijk is dit niet perfect, maar dit kan nu eenmaal nooit perfect als je geen unique IDs hebt.

[P_Tingen]

Precies. Hoe erg is het wanneer je pulsen aan elkaar koppelt die niet bij elkaar horen? Als je op de bovenste lijn 2 pulsen hebt, en op de onderste 1 is het duidelijk dat je er een mist. Maar welke?

[CH4OS]

Dat kan je eventueel ondervangen, door elke puls zijn eigen start- en stopsignaal te geven. Met combinaties (zeker zonder unique ID's) is het gewoon moeilijk een goed algoritme te krijgen. Want wat, als een combinatie bijvoorbeeld wijzigt? En wat kun je dan nog met je historie / archief?

[ Voor 51% gewijzigd door CH4OS op 22-01-2016 12:31 ]

[pedorus]

Overigens lijkt het me ook een kwestie van eerst iets simpels doen en kijken hoe goed het werkt. Als je iets hebt gedaan, dan heb je als het goed is twee tellingen voor foutjes, die erg laag zijn. Als dit niet zo is, ga je kijken waardoor dat komt. Daarnaast heb je allemaal tussentijden. Die kun je in een histogram/density plot zetten. Als de histogram onlogisch eruit ziet, dan ga je ook kijken waardoor dit komt.

[Xiphalon]

Je kan als je puls 1 ontvangt, op een queue de tijd zetten, en als je een puls 2 ontvangt het eerste item uit de queue terughalen, dat zou dan je starttijd moeten zijn. Dit kan live bij ontvangen of achteraf als je van links naar rechts door de tijd loopt.

Mis je dan een puls 2 gaat het wel stuq

[farlane]

Als je eerste op beide inputs de foute pulsen eruit filtert kan je de pulsindexen gebruiken om de tijd te matchen. Welk filter je daarvoor moet gebruiken is aan jou om te bepalen, maar waarschijnlijk iets met een min en max interval?

[WVL_KsZeN]

P_Tingen schreef op vrijdag 22 januari 2016 @ 12:07:
Hoeveel van die pulsen heb je? Is dit een continuestroom van pulsen of is het te overzien wat je binnenkrijgt? Als dat laatste het geval is en je hebt hooguit een paar honderd of paar duizend pulscombinaties zou je kunnen proberen de 2e tijdsbalk zo te verschuiven dat de gemiddelde afwijking tussen alle bij elkaar horende pulsen zo klein mogelijk is (en 'bij elkaar horend' zou je dan kunnen definieren als ergens tussen 3 en 6 seconden). Weesjes die geen partner hebben negeer je dan verder, wat je algoritme een stuk overzichtelijker maakt.

Ik heb even geteld, in de drukste periode krijg ik +- 1000 pulsjes per uur per detector. Op een dag krijgt een koppelpaar tussen 4000 en 10.000 pulsjes. Als ik 10.000 pulsen aan 10.000 ga koppelen en alle verschillen ga uitrekenen, dan loopt het uit de hand : er zijn dan 10.000*10.000 = 100.000.000 koppeltjes. De helft daarvan onzinnig dus 50.000.000 koppeltjes.. Dat zijn er veel te veel... Ik moet dus alleen maar zinnige koppeltjes gaan evalueren.

Misschien moet ik een algoritme als volgt maken :

code:

//vind alle zinnige koppels
-loop over alle pulsjes van detector 1
   -vind alle pulsjes van detector 2, die in een interval van X tot Y seconden na dit pulsje plaats vinden en sla ze op.
   -tel het aantal keer dat een pulsje in een koppel voorkomt

// door alleen zinnige koppels te bekijken hebben we pulsjes waar geen andere puls bijhoort al weggefiltert

//keur alle simpele koppels goed
-loop over alle gevonden koppels
    -komen beide pulsen in dit koppel maar 1 keer voor in een koppel? -> dan is dit een goed koppel
        -kopieer dit koppel naar de lijst met uiteindelijke koppels

// nu hebben we nog koppels over die op verschillende manieren gekoppeld kunnen worden
-hoeveel zijn dat er nou? ->> eens testen! Als het er weinig zijn tov het aantal goede koppels maakt het me niks uit :-)

Ik denk dat ik hiermee al redelijk ver kom, alleen zie ik niet zo hoe ik dan verder moet met de lastige koppels. Misschien eerst maar eens uitwerken en dan kijken hoeveel dat er nou zijn..

[CH4OS]

En wat als je een van de twee een pulsje of meerdere pulsjes mist? Dan gaat het helemaal scheef lopen. Ik denk niet, dat twee verschillende pulsjes hier handig in is. Ik zou dus gewoon de pulsjes aanpassen en zorgen dat de puls zelf een start- en stopsignaal geeft. Vervolgens meet je de tijd tussen die twee pulsjes in.

Mocht je dan een puls missen, kun je altijd een 'timeout' meegeven, wanneer een bepaalde puls te lang heeft geduurd bijvoorbeeld.

[Invisible_man]

Als je nu een stack maakt waarbij je bij elke startpuls een datumtijdstempel toevoegt bovenaan de stack en bij elke stoppuls de onderste (en dus oudste) item daar uithaalt en aan de hand van die tijdsstempel gaat vergelijken. Zoals ik het van je begrijpt zou een nieuwe stoppuls altijd moeten horen bij de oudste nog niet verwerkte beginpuls.

Kan je als bewaking nog een regel toevoegen dat als er te veel items in de stack staan (en er waarschijnlijk meer startpulsen dan stoppulsen zijn geweest). Hoe groot die stack maximaal mag worden kan je dan met jouw schatting wel bepalen + een marge.

De truc is dus niet alle pulsen gaan opslaan, maar alleen degene die je nog niet gekoppeld hebt aan een stoppuls.

En 1000 pulsjes per uur veel? Ik heb een toepassing met een roratry encoder die elke omwenteling 1000 pulsen geeft (in twee kanalen zodat ik ook richting kan bepalen) en dat bij een toerental van 1500 RPM (90.000.000 pulsen per uur) waarbij ik elke 10 ms een exact toerental moet bepalen.

[ Voor 6% gewijzigd door Invisible_man op 22-01-2016 13:10 ]

[P_Tingen]

Ik gok dat TS zelf de pulsen niet kan beïnvloeden en het moet doen met wat hij ontvangt (industriële omgeving?)

Suggestie voor vinden van koppels:

code:

//vind alle zinnige koppels
-loop over alle pulsjes van detector 1
   -vind alle pulsjes van detector 2, binnen interval van X tot Y sec vanaf puls en sla ze op.
     (je hebt nu een 1-op-meer)
   -loop over alle gevonden pulsen van detector 2
     - zoek terug in de tijd in de pulsen van detector 1 of je een match kan vinden . Zo ja: zinnig koppel

[Invisible_man]

P_Tingen schreef op vrijdag 22 januari 2016 @ 13:13:
Ik gok dat TS zelf de pulsen niet kan beïnvloeden en het moet doen met wat hij ontvangt (industriële omgeving?)

Suggestie voor vinden van koppels:

code:

//vind alle zinnige koppels
-loop over alle pulsjes van detector 1
   -vind alle pulsjes van detector 2, binnen interval van X tot Y sec vanaf puls en sla ze op.
     (je hebt nu een 1-op-meer)
   -loop over alle gevonden pulsen van detector 2
     - zoek terug in de tijd in de pulsen van detector 1 of je een match kan vinden . Zo ja: zinnig koppel

Industrieel of niet, waarom zou dat moeten uitmaken? Waar denk ik de oplossing zit is of je het realtime uitvoert, of achteraf. Als je het realtime (dus direct bij het binnenkomen van de pulsen) doet heb je alleen te maken het tijdelijk opslaan van de niet gekoppelde startpulsen en schrijf je het resultaat pas weg wanneer je een match tussen twee pulsen hebt. Als je het achteraf doet moet je eerst een hele bult data door, al zou je daar een zelfde benadering bij kunnen gebruiken door vanaf het begin er door heen te lussen.

[P_Tingen]

Invisible_man schreef op vrijdag 22 januari 2016 @ 13:18:
[...]
Industrieel of niet, waarom zou dat moeten uitmaken?

Dat maakt op zich niets uit. Een paar reacties eerder werd voorgesteld om de pulsen aan te passen en een id mee te geven. In een industriële omgeving heb je vaak te maken met machines waar je geen invloed hebt op de pulsen die ze uitzenden, dus zul je het moeten zien te redden met wat je binnenkrijgt.

Met je oplossingsrichting ben ik het overigens volkomen eens

[ Voor 6% gewijzigd door P_Tingen op 22-01-2016 13:23 ]

[CH4OS]

In een industriële omgeving zal er vast ook een leverancier zijn, die hierin support kan geven.

[Invisible_man]

P_Tingen schreef op vrijdag 22 januari 2016 @ 13:22:
[...]

Dat maakt op zich niets uit. Een paar reacties eerder werd voorgesteld om de pulsen aan te passen en een id mee te geven. In een industriële omgeving heb je vaak te maken met machines waar je geen invloed hebt op de pulsen die ze uitzenden, dus zul je het moeten zien te redden met wat je binnenkrijgt.

Met je oplossingsrichting ben ik het overigens volkomen eens

Nee ok , dan snappen wij elkaar!

Ik ben juist met mijn werk (industrieel programmeur) altijd in een industriële omgeving en zit daardoor wat dichter op die techniek en heb zo dan ook meer invloed op het soort signaal ergens uit moet komen. Doordat je in dergelijke systemen vaak qua resources (cpu snelheid, geheugen) vaak wat beperkter bent, al wordt dat de laatste jaren al een stuk beter, wordt je ook meer gedwongen om de verwerking van wat grotere hoeveelheden data zo efficiënt mogelijk op te lossen. Vaak zit de oplossing dan ook niet alleen in hoe je het oplost, maar ook in waar je het oplost. Zo ook hier, achteraf zit je met een hele bult ruwe data. Verwerk je het direct bij binnenkomst kan je dat al makkelijker tot verwerkte paren terugbrengen.

[WVL_KsZeN]

Ik schrik niet zo van de hoeveelheid data hoor :-)

Mijn tool kan de data van 1 dag makkelijk in minder dan een seconde inlezen, parsen en visualiseren (het screenshot is van mijn eigen tool). Ik heb verder geen invloed op de data, ik weet alleen of er op een bepaalde tiende-seconde signaal was (1) of niet (0). Daaruit bepaal ik de pulsjes (tijdstip en duur van de puls).

Ik weet verder dus niet welke pulsen bij elkaar horen, ook niet als ik realtime de data binnenkrijg. Het matchen moet ik dus zelf doen.

Of nou ja, 'moet', ik wil eenmalig iets weten en heb geen zin om handmatig een paar duizend pulsjes te gaan zitten turven..

Ik ga maar eens klussen zodat ik in ieder geval alleen maar interessante paartjes heb, en van daaruit maar weer verder.

[ Voor 8% gewijzigd door WVL_KsZeN op 22-01-2016 15:09 ]

[farlane]

WVL_KsZeN schreef op vrijdag 22 januari 2016 @ 12:57:
[...]
Misschien moet ik een algoritme als volgt maken :

Je gaf aan dat detector 1 ook dubbele pulsen gaf, die filter je zo volgens mij niet uit.

[diondokter]

Invisible_man schreef op vrijdag 22 januari 2016 @ 13:09:
Als je nu een stack maakt waarbij je bij elke startpuls een datumtijdstempel toevoegt bovenaan de stack en bij elke stoppuls de onderste (en dus oudste) item daar uithaalt en aan de hand van die tijdsstempel gaat vergelijken. Zoals ik het van je begrijpt zou een nieuwe stoppuls altijd moeten horen bij de oudste nog niet verwerkte beginpuls.

Dit is toch het makkelijkst?
Hier zou je iets als dit kunnen doen:

C#:

Queue<DateTime> detector1Pulses = new Queue<DateTime>();

void OnDetector1Pulse()
{
    detector1Pulses.Enqueue(DateTime.Now);
}

void OnDetector2Pulse()
{
    TimeSpan timeBetweenPulses = DateTime.Now - detector1Pulses.Dequeue();
}

Of zie ik nu iets over het hoofd?

[pedorus]

WVL_KsZeN schreef op vrijdag 22 januari 2016 @ 12:57:
Als ik 10.000 pulsen aan 10.000 ga koppelen en alle verschillen ga uitrekenen, dan loopt het uit de hand : er zijn dan 10.000*10.000 = 100.000.000 koppeltjes. De helft daarvan onzinnig dus 50.000.000 koppeltjes.. Dat zijn er veel te veel... Ik moet dus alleen maar zinnige koppeltjes gaan evalueren.

100.000.000 zijn er eigenlijk nog niet eens zoveel vind ik. Ik zou nog steeds eerst iets als mijn O(n) aanpak doen en dan kijken of je het wel wil verbeteren. In principe kan dat beter, maar is dat wel nodig? Wat voor het theoretisch 'optimale' algoritme nog uitmaakt is of de 'objecten' elkaar kunnen inhalen of niet. Zo ja, dan zou je bijvoorbeeld alle zinnige koppels kunnen sorteren op waarschijnlijkheid, en steeds de eerst mogelijke match pakken die nog niet is uitgesloten. (Of eigenlijk hoef je niet te sorteren, maar kun je een heap gebruiken.) Als inhalen niet kan, dan zit er correlatie tussen de waarnemingen, en ligt het anders. Dan zou je bijvoorbeeld het O(n) algoritme kunnen hanteren, en daarna kunnen kijken of je verschuivingen kan doen die de standaarddeviatie doen verminderen. Mogelijke zinnige verschuivingen zijn altijd richting een ongematchte puls, dus dat zijn er waarschijnlijk niet zoveel.

[WVL_KsZeN]

Volgens mij koppel ik dan een puls van detector 2 aan beide pulsen van detector 1 en is het geen 'eenvoudige' puls meer. Dan valt die dus vanzelf in het bakje 'moeilijke pulsen'.

[Smelt]

nvm had eerst alles moeten lezen
ik heb niet alles doorgelezen maar als je 100% zeker weet dat je altijd een pulse van beide detectoren krijgt en de pulsen altijd opvolgend zijn dan hoef je er maar 1 te koppelen en weet je automatisch dat de volgende van beide altijd bij elkaar horen

[ Voor 7% gewijzigd door Smelt op 22-01-2016 17:06 ]

[WVL_KsZeN]

Smelt schreef op vrijdag 22 januari 2016 @ 17:04:
ik heb niet alles doorgelezen maar als je 100% zeker weet dat je altijd een pulse van beide detectoren krijgt en de pulsen altijd opvolgend zijn dan hoef je er maar 1 te koppelen en weet je automatisch dat de volgende van beide altijd bij elkaar horen

Dan zou het makkelijk zijn :-). Helaas weet ik dat niet zeker, sterker : ik weet zeker dat dat niet zo is. Soms geeft detector 1 een puls en krijg ik geen bijbehorende puls op detector 2. Andersom kan ook.

Gisteren telde ik bijvoorbeeld 9785 pulsen op detector 1 en 9973 pulsen op detector 2. Dat is dus net wat het moeilijk maakt.

Het is ook niet erg als ik alle pulsen niet kan matchen, het grootste deel is goed genoeg.

[RobIII]

Als ik even goed kijk naar je afbeeldingen dan komt je 7e puls op de 2e sensor VOOR de puls van de eerste sensor? Of is dat een gevalletje waar een puls 'verloren' is gegaan?

Ik zou denk ik eens kijken naar phase correlation / cross correlation / cross auto correlation -achtige algoritmen waarbij je effectief beide signalen probeert zo goed mogelijk "passend" op elkaar te schuiven. Daarbij heb je een "marge" van +/- 9 seconden (3 naar links / 6 naar rechts) +/- nog een paar seconden "for good measure / voor de zekerheid") om daaruit een "best match" te kiezen. Daarna is het gewoon voor de voet signalen lezen die 't dichtst bij elkaar liggen.

Daarbij hoef je natuurlijk niet alle ~10K pulsen van een dag proberen te alignen maar kun je volstaan met een representatieve "steekproef" van, zeg, 1000 pulsen over de hele lengte die je dan ook nog maar "binnen de marge" hoeft te alignen. Gewoon het locale minimum zoeken en die hanteren.

[ Voor 29% gewijzigd door RobIII op 22-01-2016 17:50 ]

[WVL_KsZeN]

Over cross-correlation had ik al nagedacht. probleem is dat je bij veel pulsen totaal geen overlap hebt als je uitgaat van de gemiddelde tijd. Zie het 2e plaatje, daar heb ik de onderste rij verschoven met het (geschatte) gemiddelde. De laatste 3 pulsen hebben totaal geen overlap.

Phase-correlatie lijkt me wel weer een interessante methode om het gemiddelde tijdsverschil te bepalen! Daar duik ik even in.

[ Voor 18% gewijzigd door WVL_KsZeN op 22-01-2016 19:00 ]

[H!GHGuY]

Ik dacht aan dit:

code:

fn enqueue_pulse(index):
  timestamp = time.now
  queue = m_queues[index]
  queue.enqueue(timestamp-m_firststamp[index])

fn diff_queues(offset1, offset2):
  index = 0
  score = 0
  while offset1 + index < m_queue[1].len and offset2 + index < m_queue[2].len and index < some_threshold:
     score += abs(m_queue[1].index(offset1 + index) - m_queue[2].index(offset2 + index))
  return score

fn drop_bad_pulses():
  int minscore = very_high_number, offset1, offset2
  for i = 1 to threshold:
     score = diff_queues(i, 0)
     if score < minscore:
        offset1 = i; offset2 = 0; minscore = score
     score = diff_queues(0,i)
     if score < minscore:
       offset1 = 0; offset1 = i; minscore = score
  while offset1 > 0:
     queue[1].dropfirst()
     --offset1
  while offset2 > 0:
     queue[2].dropfirst()
     --offset2

  # hier zijn de queues gebalanceerd en heb je de gelijke samples op gelijk niveau.
  # natuurlijk moet je ze nog annoteren met de echt nuttige data...

Ik ging er voor de veiligheid ook even van uit dat de correlatie ook negatief kan zijn. Zoniet kan je 1 van de 2 paden verwijderen.

[WVL_KsZeN]

Ik heb wat zitten programmeren, de resultaten zijn bemoedigend :-)

Gegeven de data van gisteren (9973 pulsen op detector 1 en 9785 pulsen op detector 2)

- er zijn 7757 eenduidige koppels te maken, dat is 77,8% van het totaal aantal pulsen op detector 1 en 79,3% van het aantal pulsen op detector 2. Bijna 80% is dan dus al bepaald!
- het komt 1121 keer voor dat een puls van detector 1 aan twee pulsen van detector 2 gekoppeld kan worden
- het komt slechts 1 keer voor dat een puls aan 3 pulsen gekoppeld kan worden

Nu moet ik de case dus nog uitwerken waarin een puls 2x gekoppeld kan worden. Ik kan me voorstellen dat het volgende vaak gebeurt : er zijn 2 gebeurtenissen vlak na elkaar op detector1 en daardoor ook 2 pulsen vlak na elkaar op detector 2. Hierdoor kan elke puls van detector 1 gekoppeld worden aan twee pulsen op de tweede detector.

Als ik dus dit zie :

-puls X van detector 1 kan gekoppeld worden aan zowel puls Y en Y+1 van detector2
-en puls X+1 van detector 1 kan ook gekoppeld worden aan zowel puls Y en Y+1 van detector 2
-puls Y en puls Y+1 van detector 2 passen beide in precies 2 koppels

dan kan ik X koppelen aan Y en X+1 aan Y+1.

Eens proberen.

[fiftyhillswest]

Misschien sla ik hier de plank volledig mis, maar wellicht kan dit probleem ook opgelost worden door iets als RANSAC. Dit algoritme een "beste" model te bouwen (of in dit geval, de verschuiving die nodig is om de signalen zo goed mogelijk op elkaar te leggen met de kleinste fout), gegeven dat er outliers zijn (dus hier punten die te ver weg liggen om te koppelen). Het is maar een idee, maar misschien kan het een oplossing zijn

[DaCoTa]

Heb je een dataset waar mensen mee mogen spelen?

En wat zijn de karakterisieken van de tijdperiode? Heeft een langere tijd tussen twee pulsen ook invloed op andere punten, of zijn de punten en tijdsperioden allemaal uniek zonder enige correlatie?

[ Voor 67% gewijzigd door DaCoTa op 23-01-2016 23:55 ]