Ithamar_code/documentation/build/html/_sources/P4_realiseren.rst.txt

*********************
Werkplaats Realiseren
*********************

In periode 3 moest er een plan geformuleert worden door groepjes om in periode 4 in een van de gebouwen van de hogeschool rotterdam een meting uit te voeren. Deze metingen moesten
voldoen aan de eisen van de aandeelhouders zoals de hogeschool rotterdam, ethisch verantwoord zijn, duidelijk aangegeven in de omgeving om gebruikers/omstaanden te informeren
van de meting en geoptimaliseerd genoeg zijn om 3-5 dagen te functioneren. Officieel is dit geklassificeerd als een groepsopdracht, dit weerhield mij niet van alleen te werken
vanwege een minder dan stabiel team. Sinds mijn team insignificant was voor dit project zal niet naar hun gereffereerd worden.

Periode 3
---------
::
    
    "there's the calm before the storm, but this was a monsoon"

Voor deze opdracht werd er "democratisch" gekozen om de metingen uit te voeren in de toiletten in het gebouw "hoogbouw museumpark". Het idee hiermee was dat het gebruik van
de faciliteiten werd gemeten door de gebruikers te meten via een IoT solutie. Deze solutie was op dit moment nog niet het doelpunt van het onderzoek en er werd meer focus gelegd
op een idee te presenteren gebaseerd op huidig beschikbare informatie en vroegtijdig contact te leggen met de aandeelhouders. 

Voor de metingen nam ik de moeite de meet locatie te verkennen en uit te beelden op een schema voor een uiteindelijk verslag. Hiermee konden de partijen ook de locatie van hun
meetappartuur vroegtijdig aangeven. Verder zocht ik (tervegeefs) contact met de aandeelhouders maar dit werdt later door een leraar verholpen sinds alle groepjes hier problemen
mee hadden. 

.. image:: werkplaats_realiseren/diagram period 3.png

Voor deze periode had ik een prototype bedacht dat om de gebruikers te meten aan de hand van bluetooth signalen in een 5-10 meter radius dat gebruik maakte van het slechte 
signaal in de toiletten en wat positionering. Voor dit prototype dacht ik eerst de hc-05 bluetooth module voor te gebruiken maar ik had voor de veiligheid 2 esp32 firebeetle 
bordjes gekocht die niet afhankelijk waren van een externe sensor om bluetooth signalen op te pikken. Onthoud dat op dit punt was het meer een paper prototype dan een solide
plan dat uitgevoerd zou worden.

ik quote een monsoon/mossoen en dat kwam aan het einde van deze periode: Er was een gezamelijk verslag gemaakt en ingeleverd (zware nadruk op de gezamelijkheid dat defintief (niet) aanwezig was).
Een van mijn teamgenoten had het verslag ingeleverd met een enkele toevoegen van sjablomen en ik had in goed vertrouwen geen credits gezet sinds ik aannnam dat het een groepsproject was
en het team een cijfer kreeg. Dit was niet het geval en ik kreeg een onvoldoende en mijn twee (kost niks kan niks) teamgenoten kregen een voldoende.

Na deze kleine debacle had ik dezelfde dag een nieuw verslag geschreven met alleen mijn aandeel met wat **"inzichtvolle"** observaties over het **"team"** warnaar ik een voldoende
kreeg en een vraag hoe ik zoveel kwaadwillendheid kwijt kon in een paragraaf.

Wat er kan worden geleerd van deze ervaring: 

1. laat nooit een willekeurig persoon jouw werk inleveren of lever minimaal je eigen versie in.
   
2. Heb in reflecties en feedback absoluut geen genade en bagatelliseer niets.

Periode 4
---------

Periode 4 was bedoeld om het apparatuur te bouwen, testen en te meten op de hogeschool en misschien later op de tech-expo te demonstreren. Het eerste wat mis ging was natuurlijk
het contact met de aandeelhouders maar dit werdt irrelevant toen een leraar dit vast zette op een week, alle metingen moesten in dezelfde week worden uitgevoerd en de school
zou posters uit printen naar ontwerp van de studenten die aan het testen waren als onderdeel van User Interaction/Experience. Verder waren er veel klasikale problemen zoals
een tekort aan kennis over stroomaanvoer/batterijcapiciteiten, hoe een apparaat kan worden geinstalleerd zonder makkelijk gesaboteerd te worden, of er wel een wifi signaal
was op de locatie en er data kon worden opgestuurd. De meeste van deze complicaties werden omheengewerkt of zelfs genegeerd en naarmate de metingen verliepen werd het duidelijk
dat deze opdracht een wake-up call was over hoe goed en hoe catastrophisch slecht een "simpel" project als dit kan gaan. 

Prototype hc-05 bl-sniffer
--------------------------

Dit prototype was opgebouwd uit een esp8266 nodemcu 1.0 gekoppeld met de hc-05. De hc-05 zou in een scan modus (vaker bekend als snif-mode) en bluetooth signalen oppikken en de
nodemcu deze zou opsturen naar een 3rde partij broker via het locale wifi netwerk. Dit was een solide plan behalve dat ik niet doorhad dat ik een hc-06 had in plaats van de hc-05
en deze sensor geen scan modus had. Ik kwam hier pas achter bij de beoordeling van van deze opdracht. Maar vanwege de levering van het nieuwe materieel had ik dit project geschrapt
4 dagen voor de meting. 

.. image:: werkplaats_realiseren/prototype1.png

Prototype ESP32 "bluetoothsniffer" firebeetle
---------------------------------------------

Dit prototype was bedacht om een meer minimalistisch en energiezuiniger product op te leveren, het firebeetle merk is bekend voor diens extreme stroombesparing in deepsleep modus
en in het esp32 model was bluetooth en wifi op het board zelf beschikbaar. In theorie zou dit bord perfect zijn voor de meting die ik wilde uitvoeren en had geen externe sensoren
nodig naast een batterij en behuizing. 

Dit project had enige complicaties waar ik niet op voorbereid was, voor starters was ik niet bekend met de esp32 architectuur en het ondankbare werk van alle bibliotheken 
opnieuw te moeten uitzoeken en toe te passen. De bibliotheken werden des te langer dit project doorging een groter probleem vanwege de gelimiteerde opslag van de esp32 en de 
veelzeidige bibliotheken die met elkaar clashde of memory overload errors. Uiteindelijk had ik wel het probleem verholpen aan het einde van de testweek alleen om te Realiseren
dat ik geen capabele batterij had voor het bord.


.. image:: werkplaats_realiseren/prototypebl2firebeetle.jpg

(prototype finale hardware)

Enkele benoemenswaardige vindingen:

1. Een groepje dacht 2 blok dozen op een vensterbank te gooien en het een dag te noemen, dit werd niet gewaardeerd en terug geroepen.

2. Een groepje probeerde met posterbuddies een sensor op te hangen hetwelk met veel gratie viel na 1 minuut en met weinig gratie landde, de micro usb poort was beschadigd in de
   val. (ik kreeg een referentie in hun verslag als "tapeguy".)

3. Mijn eigen groepje probeerde resultaten te fabriceren omdat ze niet de moeite namen om batterijen te kopen/onderzoeken voor het project en werkte met een powerbank. (powerbanks
   vallen uit als ze onder een zekere waarde stroom leveren dus dit zou nooit gewerkt hebben met een deepsleeping sensor) 

4. Twee volledig getteste, ontworpen en gedocumenteerde prototypes die niet of niet goed genoeg werken laten veel meer inzet zien dan een semi-werkend protoype met nauwelijks
   documentatie of experimentele inbreng. fortis fortuna adiuvat.

De metingen liepen ook niet heel voordelig aan mijn zeide; de hc-05 bleek later pas een hc-06 te zijn die geen sniff modus kon uitvoeren en werdt geschrapt toen de firebeetle 
enkele dagen voor de metingsweek binnenkwam. Ik had al code geschreven voor wat ik nam zou draaien op de firebeetle maar had geen idee dat de esp32 en esp8266 compleet andere 
modules en bibliotheken gebruikten. Hierdoor verviel de code en moest ik spontaan deze nieuwe architectuur leren om passende code te schrijven hetwelk bijna het einde van mijn
project werdt.

Naast het probleem van de code was er nog een probleem hetwelk ik niet wist/kon oplossen in de meetweek: De firebeetle esp32 heeft slechte documentatie over diens stroomeisen
en hierdoor had ik geen batterij van correcte sterkte beschikbaar om het experiment te laten verlopen. Na 8 dagen te hebben verspilt aan de firebeetle besloot ik met gratie 
mijn verliezen te nemen en geen poging tot een meting meer te doen maar inplaats daarvan een extensieve documentatie te maken over mijn vindingen. Mijn logica was dat ondanks
dat ik het voornamelijke doel niet had behaald ik wel veel geleerd had van dit experiment hetwelk veel meer waard was dan een sensor die draaide voor 5 dagen zonder dat ik iets
nieuws had geleerd tijdens het hele process.

::
    
    Now here's the kicker, i survived... but my team did not!

Voor de beoordeling kreeg je 2 cijfers, het prototype dat voor 80% gold en de reflectie die voor 20% gold. Voor het prototype miste ik aanzienbaar wat vanwege het gefaalde 
project en scoorde ik maar een 4.9, maar voor de reflectie scoorde ik een 8.5. In combinatie maakte dit een 5.6 als eindcijfer en was ik over voor het vak. hetzelfde kon niet
gezegd worden over mijn halfslachtige team.


Nasleep
-------

Al had ik het vak gehaald was dit noch niet het einde van dit prototype. Sinds dit de laatste periode was van het schooljaar werd er nog een expo georganiseerd voor alle 
opleidingen om een kans te creëren voor studenten en bedrijven om elkaar te ontmoeten en mogelijk een stageplek te regelen. Sinds dit de hogeschool rotterdam is werd dit ook 
gelijk gebruikt als een herkansing en deel van een ander vak dat ook vereist was om het jaar te behalen. Tijdens deze tech-expo werden studenten verwacht zichelf te verkopen
aan de bezoekende bedrijven. Tijdens dit evenement had ik de "gefinaliseerde" versie van de Bluetooth sniffer "firebeetle" ingezet sinds dit gold als een IoT project en min 
of meer mijn kronende unieke project was dat liet zien dat ik een experimentele interesse had in mijn vak. Op dit punt had ik wel de code werkend gekregen van het project
maar was ik niet verder gegaan met het probleem van de batterijen in enige vorm van doorbraak. Dit prototype ving wel wat aandacht maar de opkomst van IoT gerelateerde 
bedrijven was schaars tot geen waardoor dit geen verdere impact heeft kunnen hebben op mijn studie.