Door Mark van der Kruit

Videoredacteur

Gathering of the Tweakers: De embedded-softwareprojecten van Laserfreak

09-10-2016 • 06:00

109

Elektronisch speelgoed ging vroeger bij Laserfreak een dag of twee mee voordat de boel uit elkaar geschroefd op de grond lag. Te nieuwsgierig was de jonge Daan Pape, naar de werking en losse onderdelen. Hij ging er vervolgens mee aan de haal en knutselde van alles in elkaar. Later groeide dat uit tot het bouwen van kleine robotjes die hij programmeerde met PIC-microcontrollers.

Van het een kwam het ander en inmiddels maakt Laserfreak onder andere z'n eigen printplaten en schrijft hij embedded software. Dit alles brengt Daan vooral samen in de Internet of Things-hoek. In 2014 ontwikkelde hij zodoende een moederbordje als concurrent van de Raspberry Pi. Ook richtte hij z'n eigen IoT-platform op.

Vorige afleveringen uit dit seizoen:
1. De geautomatiseerde Lego-treinen van Almightyarjen
2. De casemods van goudsmid Femketoele
3. De chiptunes van Gameboy-modder Noedell
4. De Elite Dangerous-simpit van RobV

Lees meer

Reacties (109)

109
109
70
2
0
6
Wijzig sortering
Wat is het een mooi filmpje geworden, ik zat echt met spanning te wachten op wat het zou worden.

Bedankt alvast voor alle fijne reacties, het is leuk om te lezen. Ik ben volop aan het verder bouwen aan het systeem en steeds de software aan het verbeteren.

Het is inderdaad mijn bedoeling om alle toestellen onderling met elkaar te laten babbelen en op elkaar te laten reageren zonder dat er een centrale cloud nodig is.
Als ik op bluecherry.io kijk (ik neem aan dat jouw systeem is?) , lijkt je platform zich te presenteren als IoT platform, wat naar mijn idee een "cloud functie" impliceert. Dat je lokale verwerking van logica nodig hebt lijkt me evident, maar volgens mij wijkt dat niet heel erg af van bestaande architecturen, de "dumb" (wireless) sensornetwerken daargelaten.

In ieder geval tof om te zien wat je allemaal al bereikt hebt. :Y)

Trouwens, heb je je het schema/PCB design zelf eigen gemaakt of heb je daar ook een studie voor gevolgd?

[Reactie gewijzigd door farlane op 25 juli 2024 09:41]

Hallo farlane,

Bluecherry.io is inderdaad mijn IoT-platform. Het unieke is dat de cloud helemaal geen data bevat en ook niets uitrekent, het is enkel een doorgeefluik naar het IoT-toestel als het ware.

Neem bijvoorbeeld een traditioneel IoT systeem zoals bijvoorbeeld Belkin Wemo. Dit systeem bestaat uit 'domme' schakelaars voor lampen en dergelijke. Via een 'app' op de smartphone kan je deze allemaal programmeren en instellen met timers. De volledige logica en alle 'smart' zaken worden echter in de cloud opgeslagen. Als de cloud er uit ligt dan werken ineens de timers niet meer en doet de app het ook niet meer.

Een ander voorbeeld is de Revolv hub van Nest, ze beslisten de cloud service uit te schakelen en ineens werkt de hub niet meer. Dit komt omdat alle 'smart' functies in de cloud zitten.

Het is mijn idee om de cloud 'optioneel' te maken en alles in het toestel zelf te steken. Zo steek ik de volledige interface, logica, smart learning functies, ... helemaal in het toestel. Het maakt niet uit wat er gebeurt met de 'cloud', die heeft toch geen invloed op de werking van het toestel en bevat niets van persoonlijke of andere gegevens.

Het schema/PCB design heb ik zelf gemaakt. Ik heb nooit elektronica studies gevolgd, enkel toegepaste informatica. Het ontwerpen van de printplaten en schema's is iets dat mij altijd al heeft geïnteresseerd en dat is steeds groter geworden :D
Ik denk dat jouw opzet (die eigenlijk niet veel afwijkt van wat we al jaren doen met distributed control/e/bedded control, PLC's etc ) eigenlijk de beste is voor *de gebruiker* terwijl de "cloud only" oplossingen die je ziet opduiken vaak beter zijn voor de leverancier want (nog meer) vendor lock-in.

Wat er overblijft voor de cloud en waar het mijns inziens ook veel meer warde toevoegt is bijvoorbeeld rapportages en management.

Iig, nogmaals kudos voor wat je al bereikt hebt :)
Bij IoT is het apparaat zelf redelijk dom en wordt alle data naar de cloud gestuurd om daar verwerkt te worden. Je kan er data analyse op op los laten en dit weer gebruiken als input om het proces te sturen. Info van een user is dan niet zo bijzonder, maar data van duizenden of miljoenen gebruikers is veel interessanter. Zo kan je bijvoorbeeld slimme meters gebruiken om realtime de energie prijs te bepalen op basis van vraag/aanbod. De oplossing van laserfreak is een embedded system met slimme logica, maar het mag zeker geen IoT heten.

Overigens is er ook een tussenvorm wat Fog computing heet. Data wordt lokaal verwerkt en alleen de metadata wordt naar de cloud gestuurd voor verdere analyse. De controllers van laserfreak hangen meer richting Fog computing.
Ik denk dat de definitie van IoT en Cloud wat verschillen per persoon : voor mij is een lokaal sensor netwerk + lokale controller/logica die ook rapporteert naar iets "op het internet" ook een IoT/Cloud oplossing terwijl jij en volgens mij laserfreak ook het pas een cloud noemen als daar ook het verwerken van de logica plaatsvindt.
Ik denk dat ze marketing termen zijn die in de blender mogen, samen met de PR lui die er mee kwamen. Het heeft niks met specifieke technologie te maken, en minder vaag dan 'een ding dat ergens iets doet' wordt het met die termen niet.
Op een platform als Azure kun je echt kiezen wat je doet in de cloud. Denk aan enkel opslag of doorgeefluik tot aan je volledige infrastructuur. Het begrip cloud is enorm breed.

Laserfreak is wel duidelijk wat hij met de cloud bedoeld. Als Azure gebruiker en C# programmeur snap ik zijn punt toch helemaal. De webserver op het device zelf draaien heeft grote voordelen.
Ik denk dat de definitie van IoT en Cloud wat verschillen per persoon : voor mij is een lokaal sensor netwerk + lokale controller/logica die ook rapporteert naar iets "op het internet" ook een IoT/Cloud oplossing terwijl jij en volgens mij laserfreak ook het pas een cloud noemen als daar ook het verwerken van de logica plaatsvindt.
Eens. Al vind ik het ook typisch 2016 dat mensen continue praten over "de cloud" en "internet of things". Er is voor commerciële domotica systemen weinig toekomst indien het niet aan een cloud dienst gekoppeld is. Dus links of rechtsom zal het verdienmodel toch via een cloud abbo lopen.
Mooi dat iemand gaat voor lokale systemen... we verbinding ons vandaag de dag veel te veel met cloud oplossingen die meestal proprietary zijn en dus voor een pure vendor lock in zorgen terwijl dit totaal niet nodig is.
Inderdaad, en we leven in een consumptiemaatschappij waar mensen moeten blijven kopen. Gaat een bedrijf niet overkop, dan zullen ze wel zodra toestellen goedkoop en ingeburgerd zijn hun "cloud" elke 2 a 3 jaar upgraden zodat ge heel uw installatie kunt gaan upgraden.
Interessante aanpak!
Het verrijken van je devices met logica, user interface en learning functies brengt wel significante onderhoudsmoeilijkheden met zich mee. Denk aan security patches uitrollen over je distributed netwerk van devices. Daarbij hebben hackers ook direct toegang tot je logica waar jij misschien intellectual property rechten op hebt. Het reverse engineeren van zulke software is vaak niet heel moeilijk. Helemaal als het ook nog eens web based is en niet lokale machine code, gecompileerd vanuit bijvoorbeeld C.

Het punt wat ik probeer te maken is als je echt een netwerk van distributed devices opzet waar er geen command and control (cloud) server is, waar ook de logica op draait, dat je dan wellicht veel complexere maatregelen moet nemen om het veilig te houden. Als je daarentegen de devices slechts als "slimme" sensoren gebruikt is de impact van je security risk veel minder groot en word je onderhoudsintensiviteit factoren eenvoudiger.
zoek mogelijk wat hulp met het programeren van een rabbitcore RCM3000 om er een 3d printer mee aan te sturen, weet jij mischien hoe dit moet?

heb ook nog andere microprocessoren die dit mogelijk kunnen (high end zoals xylink virtex spartan, ect) (dankzij m'n vader)
Iha is het ontwikkelen met een general purpose MCU wat makkelijker op te pakken dan het ontwikkelen mbv een FPGA. De meeste 3D printers hebben ook niet de specifieke uitdagingen waarvoor je een FPGA zou gebruiken : wat communicatie en motor control dingen kunnen de meeste MCU's wel.

Dat wil natuurlijk niet zeggen dat het niet kan, of dat het niet leuk zou zijn :)
de rabbit core's hebben ondersteuning voor steppermotors.
net als de FPGA's.

moet dan mogelijk wel via een prototype board de pinouts veranderen, maar qua voltage zou het wel moeten werken, Zou dan wel een hardwarematige driver maken indien de pinout verandern niet werkt.,

heb daarnaast ook enkele andere fpga's en microprocessoren.

dus als mensen willen helpen zou het leuk zijn.
(heb helaas weinig verstand van programmeren in dynamic-C/ andere programma's)

type 3d printer dat ik wil maken is een delta3d printer.
aangezien dit qua bouwen gemakkelijker is. mischien ook qua programmeren.
aangezien er maar 4 motoren aangestuurd hoeven te worden (6 als ik een 3 coler 1 extruder wil)
Ik zou zelf niet kiezen voor die Rabbit eigenlijk, want dan zit je meteen ook vast aan National.
Neem iets wat je in "normaal" C kan programmeren zodat je later meer keuzes hebt mocht dat niet lekker uitpakken.
mogelijk kan je in de rabbit ook met normaal C programeren. aangezien het ongeveer dezelfde programeer taal is.

zoals ik al had gezegd in 1 van m'n posts dat ik weinig kennis had van programeren.

wat bedoel je trouwens met national?

[Reactie gewijzigd door darknessblade op 25 juli 2024 09:41]

Kies dan door een RAMPS 1.4 bordje van bijvoorbeeld banggood.

Software (Marlin) is dan al 'af'. Heb hierop ook een 3d printer gebouwd.

[Reactie gewijzigd door ScoeS op 25 juli 2024 09:41]

het probleem is dat ik niet zeker weet of zo'n ramps bordje werkt met de rabbitcore RCM 3000.

aangezien de pinouts anders zijn dan bij een arduino.

het kan zijn dat het mogelijk gewoon werkt met een jumperboard, die de correcte pinout change heeft, maar dit zou ik dan moeten testen.

de rabbit core RCM kan namelijk ook in een master-slave setup werken en zo nog meer mogelijkheden hebben dan met maar 1 rabbit core
Hallo darknessblade,

Het rabbitcore bordje kende ik niet, het ziet er een leuk systeempje uit. Zoals farlane ook zegt zou ik het zeker niet met een FPGA zoals de xilinx aanpakken (al is het natuurlijk een uitdaging om dit wel te doen natuurlijk, maar dan zou ik eerder bv. een slicer IC proberen maken)

Via de I/O poorten kan je de stappenmotoren aansturen. Ik denk dat ik zou beginnen met het proberen porten van bv. de Marlin firmware (https://github.com/MarlinFirmware/Marlin) naar de RabbitMCU. Als dat werkt kan je beginnen ethernet functies toe te voegen.
wat voor soort printers kan je aansturen met marlin? cartesian of delta?
in welke programmeer taal is de marlin 3d printer firmware geschreven?
aangezien de rabbit 3000 dynamic-C gebruik (v9.x.x)
Ik heb deze marlin firmware draaien op mijn Prusa i3, een cartesian (x, y, z) printer dus. De firmware is in de arduino C++ variant geschreven. Als je deze wilt porten naar de RabbitMCU zal het hem dus vooral zitten in het porten van de Arduino libraries die de Marlin firmware gebruikt denk ik.
denk dat het dan vooral veel porten van code is.
https://en.wikipedia.org/wiki/Rabbit_Semiconductor

aangezien de arduino gebaseerd is op een amtel processor.

waarbij dynamic C meer gericht is op multitasking
"The Rabbit has IX, IY and SP, whereas the AVR (amtel) has X, Y and Z."
---
de rabbit heeft denk ik vanuit zichzelf al native ethernet ondersteuning (slave-processor)

----------
gelukkig is er genoeg electronica spul dat ik kan gebruiken (van m'n vader)
om zo een werkend systeem te maken. (vooral de stepper motor drivers)
----

[Reactie gewijzigd door darknessblade op 25 juli 2024 09:41]

Leuke aflevering! Helemaal tof natuurlijk dat je nu al bezig bent met het doorgeven van kennis aan studenten. En natuurlijk heerlijk om te zien dat je zo bezig bent met wat je leuk vindt.

Ga zo door. :)
Ken je OpenRemote? http://www.openremote.com/
You blew my mind, prachtig gewoon waar je allemaal aan het werken bent? Kan niet wachten in de toekomst meer te horen/lezen over jouw projecten! :)
Ik zou voor de Raspberry Pi gaan. Waarom? Wordt wereldwijd goed ondersteunt en er is zeer veel software en oplossingen voor te vinden met de nodige elektronica.
Tsja, dat is natuurlijk volledig afhankelijk van wat je eisen zijn.
De Pi verbruikt 6x zoveel stroom en is minder betrouwbaar begrijp ik.
Een Pi vind ik zeer betrouwbaar. Komt in mijn geval ook omdat er wereldwijd zeer veel gebruikers mee aan de slag zijn en foutjes ( in de software ) melden cq aanpassen. Hoeveel mensen werken er met dat systeem uit de video? In industriële omgevingen moet betrouwbaarheid absoluut op nummer 1 komen. Vandaar dat als ik iets bouw voor de industrie ik voor zoveel mogelijk bewezen standaard componenten ga.
Een Pi vind ik zeer betrouwbaar.
De zwakste schakel van de RPi is, zoals de video ook aanhaalt, de sd kaart. Ik heb er al verschillende versleten, ondingen zijn het!
Het DPT board gebruikt flash. Hardwarematig stukken beter (wel niet journalised, weet niet of dat bestaat?).
Als je voor je industriële omgevingen RPi's gaat gebruiken raad ik je aan goed na te denken over een recovery plan, en/of een verzekering te nemen.
Je verpest het wel een beetje ;)
Waarom zelf met een RGB ledstrip gaan prutsen als je al kant en klare oplossingen heb.

Denk dat de motivatie vooral is dat je iets mist wat je wilt gebruiken en je weet zodanig veel van het onderwerp dat je geen communitie nodig heb om je ding te kunnen doen.
Daarnaast kan ik het me voorstellen dat Daan het ook gewoon erg leuk vind om zelf dingen in elkaar te knutselen (zeker niet on eerbiedig bedoeld)
Maak zelf ook printen b.v. arduino shields voor een elektrische grasmaaier. Maar in dit geval zorg ik dat ik voor een standaard arduino gekozen heb. Ik wil niet de hobby van een ander een beetje verpesten maar als iets goed is en het heeft zich goed bewezen gebruik ik het liever dan zelf het wiel opnieuw uit te zoeken.
Cool! Fijn ook dat IOT en encryptie eens in een zin genoemd worden. Dat kan nog groot worden.

Hoe kom je met dat bordje eigenlijk van ontwerp tot product? Na ontwerp bestel je een oplage via een fabriek ergens ofzo?
Ja dat klopt, je stuurt je ontwerp in en dan heb je 2 weken later je PCB in huis. Als je veel experimenteert en de ontwerpen niet te complex zijn is het ook mogelijk om het gewoon thuis te maken, hier heb je wel wat spullen en chemicaliën voor nodig uiteraard.
Niet de meest gezondste hobby, laserfreak heeft wel een nette opstelling, maar over het algemeen kun je beter het uitbesteden aan een chinees/pool die voor een paar euro zo'n print voor je maakt.

Overigens hangt de prijs meestal af van hoe snel je het wilt hebben en hoe complex (oppervlakte en aantal lagen), als je tijd genoeg hebt (dus goed planned) kun je redelijk goedkoop uit zijn.
Anoniem: 145867 @Basszje9 oktober 2016 21:52
Gewoon je ontwerp opsturen naar China. Zitten wel wat restricties aan maar is spot goedkoop. Je kan er eigenlijk niet meer zelf voor etsen....
Anoniem: 609631 9 oktober 2016 08:44
werkt prima op chrome

slimme gast, heeft een mooie werkplaats opgebouwd

top trouwens dat die cloud negeert, vindt dat bedrijven zich daar te veel op richten

[Reactie gewijzigd door Anoniem: 609631 op 25 juli 2024 09:41]

Cloud is uiteindelijk gewoon een marketing term die aangeeft dat je iets niet lokaal doet maar op afstand, op het internet.

IOT combineren met "niet in de cloud" lijkt mij dan ook een contradictie te zijn.
laten we het dan "Intranet of Things" gaan noemen?? :D
Natuurlijk kan het zonder de cloud nog altijd prima internet of things heten. Je kunt makkelijk alles thuis draaien(dus niets in de cloud), en er nog steeds via het internet bij kunnen. Tenzij je "de cloud" definieert als het internet zelf, want dan is je huis immers onderdeel van "de cloud" :P Maar zo zie ik het niet, bij "de cloud" denk ik gewoon aan "een x aantal servers ergens in een serverpark".
Ik denk eerder aan verschillende serverparken als het een goede implementatie van Cloud computing is. Juist dat het beschikbaar is als dat serverpark problemen heeft.

Totaal irrelevant aan het topic uiteraard.
NOT (Network of things) klinkt weer niet zo lekker.

Voor mij valt openhab ook onder iot maar het werkt uitstekend als het alleen offline gebruikt wordt.
Meer internet caplible ipv required (misschien zou je cloud ook kunnen zien als een groep met elkaar communicerende devices wat ook lokaal kan zijn)

De definitie van "iot zonder cloud" mag misschien incorrect zijn maar ik ben er wel een voorstander van (weerbericht van een website afhalen zie ik niet als de cloud maar naar mijn idee wordt de term ook nog wel toegepast als het maar marketing technisch meerwaarde heeft).
Voor zover ik weet zijn voor cloud gerelateerde dingen servers nodig die iets doen, danwel opslag van data of verwerking van berekeningen. Als het goed is doen IoT apparaten niets anders dan via het internet communiceren, zonder dat daar op een externe locatie een speciale server voor nodig is (de standaard dingen voor internet buiten beschouwing gelaten dan).
Wat ik eigenlijk begrijp uit zijn plannen is dat het een soort can-bus systeem will ontwikkelen zoals het in de auto te vinden is, maar dan voor in huis (even terzijde gelaten als het nou draadloos is of niet)? Of heb ik het dat verkeerd begrepen?
Het lijkt erop dat hij nog veel verder wil gaan dan dat.

Los van hoe de devices met elkaar communiceren, draadloos of niet, vind ik het idee erg knap dat hij eigenlijk een embedded distributed platform wil ontwikkelen van sensoren en actoren. Alle elementen in het netwerk hebben vervolgens de mogelijkheid om andere elementen uit te lezen en daarop te reageren.
Het feit dat je dus geen dedicated controller nodig hebt, laat staan toegang tot de cloud, biedt potentieel al veel meer veiligheid dan de traditionele iot-gedachte dat alles met alles moet kunnen "praten".


In de praktijk klinkt dit voor mij als een een platform dat vergelijkbaar is met z-wave en openhab bijvoorbeeld, maar dan gedistribueerd over alle componenten.

Maar ik kan er ook volledig naast zitten :)
Het lijkt erop dat hij nog veel verder wil gaan dan dat.

Los van hoe de devices met elkaar communiceren, draadloos of niet, vind ik het idee erg knap dat hij eigenlijk een embedded distributed platform wil ontwikkelen van sensoren en actoren. Alle elementen in het netwerk hebben vervolgens de mogelijkheid om andere elementen uit te lezen en daarop te reageren.
Het feit dat je dus geen dedicated controller nodig hebt, laat staan toegang tot de cloud, biedt potentieel al veel meer veiligheid dan de traditionele iot-gedachte dat alles met alles moet kunnen "praten".
Naar mijn kennis over het systeem in een auto, is dat precies wat daar gebeurt. Alle sensoren en actuatoren in een auto die geven/halen hun informatie op de CAN en er is niet 1 module de alles regelt. Er is dus niet een 'host' zonder tussen komst van een cloud.

(of begrijp ik jou nou verkeerd)
Volgens mij zeggen we hetzelfde :)
Ik heb echter zelf geen kennis van hoe het in een auto werkt.


Zoals hieronder ook al wordt aangehaald, knap dat hij dit wil doen zonder de cloud, of dat het op z'n minst optioneel is!
Dan begreep ik het toch goed.

Dat het idd zonder de cloud werkt lijkt mij een veel betere basis. Geeft ook de mogelijkheid om het zonder service provider te doen (die daar graag geld voor vragen).
Dan zou je idd altijd nog een optionele module kunnen toevoegen die dat wel doet.
In België zijn er reeds twee bestaande domotica-fabrikanten die volgens hetzelfde principe werken. Enerzijds is er DuoTecno en anderzijds Teletask.

DuoTecno: http://www.duotecno.be/
Teletask: http://www.teletask.be/home.aspx?lang=en
Tijdens mijn studie heb ik een fieldpoint systeem van National Instruments gebruikt, met relais schakelingen, Temperatuur lezers en 8 kanaals analoge I/O voor het aansturen van mijn meetopstelling. De software draaide autonoom in de hoofdmodule. Is dat ongeveer hetzelfde als wat jij ontwikkeld hebt? (en is het een stuk goedkoper, dat spul van NI is duidelijk niet goedkoop :)).
Hallo DrVic,

Het fieldpoint systeem van NI ken ik niet meteen. Maar de CAN-bus modules die ik ontwikkelde hebben inderdaad een soortgelijke functionaliteit als ik dit zo lees. Ik heb een digitale module, analoge module en PT100(0)-module gebouwd die allemaal op de bus zitten. Je kan deze allemaal uitlezen/aansturen met het DPT-Board.
Ik ben wel benieuwd naar die 0-10V en 0-20mA chip. Is dat gewoon een kant en klaar reference design ontwerp?
Knap. Student zijn en zo al aan het werk zijn. Ik kan me heel goed indenken dat jij al geslaagd bent, voordat je thesis af is. Ik begrijp nog niet de helft van wat je allemaal doet, maar het lijkt me zeer indrukwekkend wat je nu al allemaal ontwikkeld hebt.

Mag ik vragen wat die belletjes-in-water-kast is waar je printplaatjes in hangen?
Dankjewel voor de leuke comment Jorgen.

Dat is een 'etsbak' en in mijn geval zit daar fijnetskristal in, ook wel natriumpersulfaat. De bak is verwarmd en de bubbels zorgen voor de goede etswerking. Deze oplossing lost het koper van de printplaat op waar dit niet langer beschermd is door een fotogevoelige lak.

Het maken van een printje gaat namelijk als volgt:
1. Belicht de print met UV-licht. Hierbij wordt alle lak belicht die straks weg moet, enkel de koperbaantjes blijven dus onbelicht.
2. Ontwikkel de print zodat de belichte lak oplost. Hierdoor komen de weg te etsen kopervlakken bloot te liggen.
3. Doe het printje in de etsbak, het niet beschermde koper lost dan op

Dat is heel kort door de bocht hoe het in elkaar zit.
Graag gedaan en dankjewel dat je de tijd neemt om het uit te leggen. Ik zie het dus als een soort belichting van een ouderwetse foto, alleen met meer stappen, om uiteindelijk over te houden wat je ontworpen hebt.

Nogmaals, heel knap wat je doet. In elk geval heel veel succes met afstuderen en met je bedrijf. Met mijn zeer beperkte kennis van het IoT denk ik dat in jouw idee zeker toekomst zit. :)

[Reactie gewijzigd door Jorgen op 25 juli 2024 09:41]

*mierenneuk modus* deze editiie is zeker oud? Hij zegt een PI heeft geen ingebouwde wifi, de 3 heeft dat namelijk als eerste wel *en dient daarmee bij mij ook gelijk als een simpel accespointje naast DNS server ergens aan de powerline in huis*
Hij heeft de eerste versie van zijn concurrent 2 jaar geleden gemaakt verteld hij in het filmpje. Toen was de pi3 er nog niet.
//Offtopic Na een aantal keer proberen werkt het filmpje prima onder W10 chrome op 1080p
//Ontopic Ik ben het geheel met zijn mening eens om de cloud te vermijden en meer via een intern/local netwerk te gaan werken om de apparaten met elkaar te laten communiceren. Met cloud altijd een internetverbinding dus extreme beveiligingen etc. vind ik het altijd maar overkill.
Dit vond ik tot nu toe één van de interessantste GotT.

[Reactie gewijzigd door davevleugel op 25 juli 2024 09:41]

Anoniem: 22438 9 oktober 2016 11:51
Knap hoor allemaal. Had ik mijn MTS opleiding afgemaakt, dan had ik waarschijnlijk ook dit soort dingen gedaan, maar nu gaat het boven mijn pet allemaal. Ik ben nog uit de tijd dat we zelf print plaatjes maakten om een analoge filmnet decoder te bouwen (wat nooit goed werkte want je moest elke 5 minuten de codering bijstellen).

Vind het wel grappig dat hij het heeft over de "klassieke" internet of things bordjes. Alsof het al decennia bestaat :p

Op dit item kan niet meer gereageerd worden.