Franse start-up gebruikt ultra narrow band voor 'internet of things'
De Franse start-up SigFox is in Frankrijk bijna klaar met het uitrollen van een mobiel netwerk dat ingezet kan worden om miljoenen eenvoudige apparaten als sensors aan internet te koppelen. De firma gebruikt daarvoor ultra narrow band, een technologie die weinig zendmasten vergt maar wel traag communiceert.
SigFox richt zich op de snel groeiende markt van producten waarin eenvoudige sensors zijn verwerkt, zoals slimme energiemeters en huishoudelijke apparaten. Via ultra narrow band kunnen deze apparaten op een relatief goedkope wijze draadloos verbonden worden met internet. Deze ontwikkeling wordt ook wel het internet of things genoemd.
Door ultra narrow band-technologie te gebruiken, hebben verbonden apparaten weinig energie nodig om een verbinding te maken. SigFox stelt dat een reguliere mobiele verbinding 5000 microwatt verstookt, terwijl een ultra narrow band-verbinding slechts 100 microwatt zou verbruiken. Bovendien heeft het mobiele netwerk van SigFox, dat in Europa opereert op de 868MHz-band, relatief weinig zendmasten nodig door het grote bereik. Voor dekking in geheel Frankrijk, een land waar de uitrol bijna voltooid zou zijn, zouden duizend antennes volstaan.
SigFox denkt dat het dankzij de toegepaste draadloze netwerktechnologie tegen zeer lage prijzen dataverbindingen kan aanbieden; een aansluiting zou jaarlijks niet meer dan een dollar kosten. Een nadeel is echter de zeer lage snelheid: een dataverbinding behaalt momenteel een snelheid van 100 bits per seconde. Dit zou echter voldoende zijn voor apparaten die slechts beperkte hoeveelheden informatie doorgeven.
De Franse start-up zegt dat het in diverse Europese landen ook zal beginnen met het uitrollen van ultra narrow band-netwerken. Ook in de VS zou belangstelling bestaan. SigFox stelt dat in de Verenigde Staten circa tienduizend antennes volstaan voor het bieden van landelijke dekking, terwijl met de reguliere mobiele technologie honderdduizenden antennes nodig zouden zijn.
Reacties (44)
Meer info over deze technologie is ook terug te vinden op http://www.vmsk.org/.
Net vandaag een presentatie van Electrolux bijgewoond en die gaan ook absoluut die kant op. En een andere Zweedse gigant is hard aan de achterliggende infrastructuur bezig en de intergratie in bestaande online structuren. Zie: The Social web of things / http://m.youtube.com/index?&desktop_uri=%2F#/watch?v=i5AuzQXBsG4
[Reactie gewijzigd door felixk op 14 november 2012 19:41]
Wat ik mij afvraag is wat electrolux moet aan die kant? Als consument heb je meestal al een internetverbinding dus is het niet noodzakelijk om weer voor een nieuwe dienst te gaan betalen. Ook al is het maar 1 dollar per jaar wat waarschijnlijk 5 euro per maand wordt voor de consument. (Ik ga ervan uit dat de fabrikant de afnemer is bij de dienst)
Hoe gaat de verbinding lopen want moet je als consument eerst verbinding maken met de servers van de fabrikant die dan via de narrow band een signaal stuurt naar het betreffende apparaat? Lekker voor je privacy.
Ik zie wel toepassingen voor consumenten maar dan zal er toch eerst naar de uitvoering gekeken moeten worden.
Hoe gaat de verbinding lopen want moet je als consument eerst verbinding maken met de servers van de fabrikant die dan via de narrow band een signaal stuurt naar het betreffende apparaat? Lekker voor je privacy.
Ik zie wel toepassingen voor consumenten maar dan zal er toch eerst naar de uitvoering gekeken moeten worden.
Geweldig dit! Heb dat probleem ooit gehad bij een project, 3G was een beetje overdreven en duur maar andere opties waren er niet. Dit zou perfect zijn!
Dit kan nog wel eens heel groot worden, ook onder hackers en diyers.
Dit kan nog wel eens heel groot worden, ook onder hackers en diyers.
Lijkt me vooral ideaal voor gps tracking. Nu loopt dat toch via duurdere gsm dataverbindingen.
Is inderdaad ook een goed voorbeeld, maar zo zijn er nog veel meer toepassingen voor dit concept.
100 bits per seconde, ofwel 12 bytes.
In een minuut kan dus ongeveer 512 bytes verstuurd worden als we de 'afval' meerekenen.
Niet erg veel en volgens mij weinig interessant. - Dan sluit ik liever alles aan op een hub die vervolgens gekoppeld zit aan mijn router.
Dan kunnen tenminste alle apparaten in één keer hun data versturen en kost me dat ook geen euro per apparaat. Want in een huishouden zijn heel wat apparaten te vinden als koelkast, diepvriezer, alle lampen, koffiezetter etc.
In een minuut kan dus ongeveer 512 bytes verstuurd worden als we de 'afval' meerekenen.
Niet erg veel en volgens mij weinig interessant. - Dan sluit ik liever alles aan op een hub die vervolgens gekoppeld zit aan mijn router.
Dan kunnen tenminste alle apparaten in één keer hun data versturen en kost me dat ook geen euro per apparaat. Want in een huishouden zijn heel wat apparaten te vinden als koelkast, diepvriezer, alle lampen, koffiezetter etc.
[Reactie gewijzigd door p0pster op 14 november 2012 13:03]
een euro per verbinding per jaar staat er 
@p0pster
Je moet hier denken aan meet data voor vanalles en nog wat.
Stel je voor dat je alleen wilt weten hoeveel auto's er over een stuk weg gaan.
Je laat dan het apparaatje alleen zo nu en dan het totaal gepasseerde auto's door geven en dat is echt wel te doen met 512 bytes
Je moet hier denken aan meet data voor vanalles en nog wat.
Stel je voor dat je alleen wilt weten hoeveel auto's er over een stuk weg gaan.
Je laat dan het apparaatje alleen zo nu en dan het totaal gepasseerde auto's door geven en dat is echt wel te doen met 512 bytes
[Reactie gewijzigd door TomBongers op 14 november 2012 13:05]
Als het alleen is om een 'puls' te geven aan/uit of iets dergelijks dan snap ik het nog wel, maar voor dataoverdracht (tweeweg), lijkt me deze techniek niet geschikt. Correct me if i'm wrong 
Je bent zeker niet wrong, maar toch snap je de essentie van het verhaal niet.
Het is JUIST om weinig data te versturen. Als je 512bytes in een minuut kan versturen en elk half uur het aantal gepasseerde auto's wil door sturen... is het echt meer dan voldoende. Of als je je verwarmin wil aan zetten en er ook nog een temperatuur aan mee wil geven. (Los van hoe dit beveiligd wordt; dat kost ook bits)
De huidige technieken om veel data te versturen hebben in het artikel genoemde nadelen: energieverbruik, aantal masten, prijzige aansluiting. Dit heeft dat dus niet.
Het is JUIST om weinig data te versturen. Als je 512bytes in een minuut kan versturen en elk half uur het aantal gepasseerde auto's wil door sturen... is het echt meer dan voldoende. Of als je je verwarmin wil aan zetten en er ook nog een temperatuur aan mee wil geven. (Los van hoe dit beveiligd wordt; dat kost ook bits)
De huidige technieken om veel data te versturen hebben in het artikel genoemde nadelen: energieverbruik, aantal masten, prijzige aansluiting. Dit heeft dat dus niet.
We zijn te verwend mensen. Je kunt best veel data opslaan in 100 bits hoor.
je moet alleen niet denken in de datatypes die we kennen. Maar je kunt een hoop doen met 100bits. Als je die 100 bits opdeelt in stukjes, waar bijvoorbeeld de eerste 7bits een identifier is van het device, en dan de rest vande bits bijvoorbeeld gebruikt als boolean, dan kun je dus nog 93 velden aan informatie opslaan in ja/nee vorm. en zo kun je op bitniveau nog een hoop dingen doen. Je moet alleen een vaste vorm aanhouden.
je moet alleen niet denken in de datatypes die we kennen. Maar je kunt een hoop doen met 100bits. Als je die 100 bits opdeelt in stukjes, waar bijvoorbeeld de eerste 7bits een identifier is van het device, en dan de rest vande bits bijvoorbeeld gebruikt als boolean, dan kun je dus nog 93 velden aan informatie opslaan in ja/nee vorm. en zo kun je op bitniveau nog een hoop dingen doen. Je moet alleen een vaste vorm aanhouden.
Ja maar je gaat hier wel leuk uit van een 1 op 1 verbinding tussen 2 apparaten die (enkel) met elkaar communiceren.
Gezien dit netwerk met meerdere 'verschillende' apparaten gebruik maakt vrees ik dat er toch iets van een netwerklaag overheen moet (IPv6?) en BAM daar gaaan je 100 bits.
Gezien dit netwerk met meerdere 'verschillende' apparaten gebruik maakt vrees ik dat er toch iets van een netwerklaag overheen moet (IPv6?) en BAM daar gaaan je 100 bits.
Voor real-time data is het te traag, maar het voorbeeld van TomBongers is perfect. Je telt op een dag het aantal auto's en stuurt 's nachts door hoeveel het er waren. Het maakt niet uit dat de data een dag later pas beschikbaar is, het gaat er om dat het vrijwel niks kost om de data te versturen. 512 bytes per minuut is 30kB per uur, daar past heel veel (geoptimaliseerde) data in.
Voor veel simpele taken, zoals het meten van lichtintensiteit, stroom/waterverbruik of de hierboven genoemde autodrukte, zal echt geen hoge bandbreedte nodig zijn. Met minder rekenkracht/ opslag/ bandbreedte etc moet er gewoon efficiënter worden omgesprongen met gegevens, je hebt namelijk altijd limieten.
En daarnaast, waarom zou het tweeweg moeten zijn als het doel is om sensordata op te halen? Meer dan een soort reset/calibratie of datarequest kan ik niet bedenken, waarbij ik me bij beide afvraag hoe wenselijk ze zijn om die commando's op afstand te geven. We kunnen natuurlijk alles wel duurder gaan maken en allemaal extra opties en bandbreedte gaan geven die eigenlijk niet nodig zijn, daartegenover staan wel altijd extra kosten (energie/geld) voor zowel ontwikkelen als gebruik. Ik denk echter dat het goed is onszelf af te blijven vragen wat echt nodig is en als dat meer blijkt te zijn dan de verbinding aan kan kun je altijd nog kijken voor een verbinding met een hogere bandbreedte.
Om ook nog even op jouw voorbeeld terug te komen van jouw huis;
En daarnaast, waarom zou het tweeweg moeten zijn als het doel is om sensordata op te halen? Meer dan een soort reset/calibratie of datarequest kan ik niet bedenken, waarbij ik me bij beide afvraag hoe wenselijk ze zijn om die commando's op afstand te geven. We kunnen natuurlijk alles wel duurder gaan maken en allemaal extra opties en bandbreedte gaan geven die eigenlijk niet nodig zijn, daartegenover staan wel altijd extra kosten (energie/geld) voor zowel ontwikkelen als gebruik. Ik denk echter dat het goed is onszelf af te blijven vragen wat echt nodig is en als dat meer blijkt te zijn dan de verbinding aan kan kun je altijd nog kijken voor een verbinding met een hogere bandbreedte.
Om ook nog even op jouw voorbeeld terug te komen van jouw huis;
- De temperatuur van je koelkast (zeg tussen 0 en 16 C = 4bit) en vriezer (zeg -32 - 0 c = 5bit) is een dynamisch zeer traag proces, waardoor eens in de minuut 10bit meer dan voldoende is.
- Lampen hebben slecht 1 bit nodig (aan/uit), maar zeg dat je gradaties wilt dan moeten 3bits toch voldoende zijn en ook voor de lampen zou eens in de minuut meer dan voldoende zijn.
de volledige besturing van een domotica exclusief beeld/geluid
rfid trackers al dan niet gecombineerd met een kassasysteem
...
rfid trackers al dan niet gecombineerd met een kassasysteem
...
Ja dat werkt ook goed bij apparaten die op zichzelf met een klein accuutje/batterij moeten draaien in de middle of nowhere. Bijvoorbeeld meetstations e.d.
100bit is wel erg langzaam ja, als het 1KB was geweest zou mooier zijn. Maar als het gegarandeerd 100bit is dan is het goed voor genoeg toepassingen.
100bit is wel erg langzaam ja, als het 1KB was geweest zou mooier zijn. Maar als het gegarandeerd 100bit is dan is het goed voor genoeg toepassingen.
niet met een hub hoor Succes met je collisions als alles tegelijk wil sturen
Daarnaast gaat dit over dingen als aansturen/uitlezen van sensoren en regeltechniek, denk aan het uitlezen van energiemeters, aan/uitzetten van lantaarnpalen, pompen, kleppen enz enz...
Succes met je collisions als alles tegelijk wil sturen Daarnaast gaat dit over dingen als aansturen/uitlezen van sensoren en regeltechniek, denk aan het uitlezen van energiemeters, aan/uitzetten van lantaarnpalen, pompen, kleppen enz enz...
De DCF77 zender in Frankfurt die de "atoomtijd" uitzend, doet dit met een bandbreedte van 1bit/sec. Ook niet bepaald snel, maar het voldoet om radioklokken mee te synchroniseren.
Met 100bits/sec zullen er toepassingen te verzinnen zijn lijkt me. Een inbraakalarm bijvoorbeeld heeft maar een beperkt aantal toestanden door te geven. Een tracker voor een auto is een andere mogelijkheid: Iedere minuut de GPS coördinaten doorgeven.
Met 100bits/sec zullen er toepassingen te verzinnen zijn lijkt me. Een inbraakalarm bijvoorbeeld heeft maar een beperkt aantal toestanden door te geven. Een tracker voor een auto is een andere mogelijkheid: Iedere minuut de GPS coördinaten doorgeven.
Maar als je een draadloze verbinding maakt met je hub (via wifi) dan verbruik je veel energie. Voor je koelkast, diepvriezer, koffiezet is dat geen probleem, maar wel voor apparaten die hun hele lifetime zouden moeten meegaan op 1 batterijtje.
Lijkt me toch interessant voor dingen als regionale verkeersinfo naar je in-car navigatie sturen, autonome weerstations een paar keer per uur info naar de meteo dienst laten sturen, hulpdiensten roepen vanaf een paaltje naast de weg, enz.
Zou een dergelijke verbinding in mobieltjes niet handig zijn om energiezuinig te checken op (status) updates, en als die er zijn deze dan d.m.v. 3G/WiFi binnen halen?
Ik vermoed dat er een iets grotere antenne voor nodig is, waardoor dit niet gaat werken in bestaande toestellen.
Antennegrootte hangt primair af van de frequentie, en die is hier 868 Mhz. Dat is vrijwel gelijk aan GSM ( ~900Mhz).. Je hebt dus niet eens een tweede antenne nodig. Met moderne Software Defined Radio zou dit misschien zelfs als een software update kunnen.
Maar als elk huishouden er zijn wasmachine, droogkast, koelkast, verwarmingsketel, energiemeter en afwasmachine gaat aanhangen, wordt het dan zelfs voor die toepassingen niet een beetje traag?
Dan zouden er alsnog meer antennes nodig zijn.
Dan zouden er alsnog meer antennes nodig zijn.
[Reactie gewijzigd door Stannieman op 14 november 2012 13:03]
Ik vermoed dat elk apparaat wel zijn eigen kanaal met 100 bit/s heeft, zolang de zendmast zelf maar voldoende bandbreedte heeft.
Nee, dat kan simpelweg niet in deze omstandigheden. Hoe zou je die kanalen toekennen? Sterker nog, ze gebruiken dezelfde frequentieband als babyfoons. SigFox kan echt jouw bestaande babyfoon op een bepaald "kanaal" duwen, zo werkt die babyfoon niet.
Nee, elk apparaat krijgt zo'n zendertje/ontvangertje. Dat is juist de kracht.
Uiteraard. Maar dat is ook niet erg: als er miljoenen apparaten zijn voor $1/jaar, dan heb je miljoenen per jaar te besteden. Bovendien zal een wasmachine niet 24/7 aanstaan, en dus ook niet 24/7 zenden.
Interessant en zeer bruikbaar denk ik. Alleen vraag ik me af hoe schaalbaar deze techniek is. Wat is bijvoorbeeld de maximale bandbreedte en wat zijn de latencies?
Als ik via een app op mijn telefoon een lamp aan of uit zet, mag dat best 1 seconden duren, maar dat is ook wel de max. Nu kost het aan of uitzetten van een lamp natuurlijk weinig bandbreedte, maar als het een RGB lamp betreft die 8bit aan kleuren weer kan geven + dimmen, en ik zet 6 lampen tegelijk aan. Dan gaat het natuurlijk nog steeds vrij snel qua bandbreedte. Zeker omdat er maar zo weinig masten nodig zijn.
Als ik via een app op mijn telefoon een lamp aan of uit zet, mag dat best 1 seconden duren, maar dat is ook wel de max. Nu kost het aan of uitzetten van een lamp natuurlijk weinig bandbreedte, maar als het een RGB lamp betreft die 8bit aan kleuren weer kan geven + dimmen, en ik zet 6 lampen tegelijk aan. Dan gaat het natuurlijk nog steeds vrij snel qua bandbreedte. Zeker omdat er maar zo weinig masten nodig zijn.
Ik denk dat in huishoudens er dan ook wel wat meer gebruikt kan worden, je lamp zou via WiFi kunnen (korter bereik, meer vermogen), of zelfs via je interne stroomnet radio kunnen versturen, zelfde concept als powerline networking. Op die manier zou je zelfs in je wasmachine een ARM boardje in kunnen bouwen wat als hij niet aan het was-rekenen is, zou kunnen bijdragen aan de rekenkracht van andere componenten van je "huis", zoals Jarvis. Distrubuted computing in je huishouden. Ideal voor smart metering gekoppeld met smart devices.
Dit moet je meer zien als een sensor tech voor bijvoorbeeld... dijken (hoewel de ijkdijk, een project waar ik ook aan mee heb geholpen, wel wat meer bandbreedte heeft), grasvelden, etc...
Dit moet je meer zien als een sensor tech voor bijvoorbeeld... dijken (hoewel de ijkdijk, een project waar ik ook aan mee heb geholpen, wel wat meer bandbreedte heeft), grasvelden, etc...
Het gaat hier vooral dan ook om data die niet 'realtime' of tegen een bepaalde termijn moet doorgeven worden. Bijvoorbeeld data van een sensor die elke paar minuten de temperatuur meet van een locatie waarvoor gewoon een trend wordt bijgehouden. Of dit data nu met enkele minuten vertraging binnenkomt zal niemand onmiddellijk boeien. Het is dan waarschijnlijk ook bedoeld voor de collectie van data zonder 'tijdsdruk'.
Het versturen van commando's over zo een lijn, zijn waarschijnlijk niet de opzet. Of toch geen commando's waar onmiddellijk informatie van terug verwacht wordt.
Het versturen van commando's over zo een lijn, zijn waarschijnlijk niet de opzet. Of toch geen commando's waar onmiddellijk informatie van terug verwacht wordt.
''internet of things'', dit deed me direct denken aan de startup van smartthings.com (funded via kickstarter).
Zoals p0pster aanhaalt wordt hier gebruik gemaakt van een hub die verbindt naar je router.
Voordeel is dat je enkel dit kastje koopt en (in pre-order allesinds) geen extra kosten meer hebt want je maakt gebruik van je eigen (snelle) internetverbinding.
Zoals p0pster aanhaalt wordt hier gebruik gemaakt van een hub die verbindt naar je router.
Voordeel is dat je enkel dit kastje koopt en (in pre-order allesinds) geen extra kosten meer hebt want je maakt gebruik van je eigen (snelle) internetverbinding.
[Reactie gewijzigd door denickmans op 14 november 2012 13:10]
Wat is de latency eigenlijk? Ik kan me voorstellen dat die behoorlijk hoog ligt als er maar 1000 masten nodig zijn voor heel Frankrijk en je in de meeste gevallen dus verbinding maakt met een mast die erg ver weg staat.
Maar wat maakt de latency uit voor dit soort dingen? Als je de luchtdruk van een sensor ergens op een mast wilt uitlezen en niet elke twee weken de accu wilt vervangen lijkt me latency het laatste wat van belang is.Wat is de latency eigenlijk? Ik kan me voorstellen dat die behoorlijk hoog ligt als er maar 1000 masten nodig zijn voor heel Frankrijk en je in de meeste gevallen dus verbinding maakt met een mast die erg ver weg staat.
Frankrijk heeft een oppervlakte van 550.000 vierkante kilometer. Dat zou dus betekenen dat je per antenne ongeveer 550 km² moet dekken, dan is de afstand binnen dat stuk ongeveer 25km.. (Even uit het hoofd allemaal).
Als je dan de snelheid van het licht bekijkt met 300.000km/s ongeveer is die 25km natuurlijk niets.
Als je dan de snelheid van het licht bekijkt met 300.000km/s ongeveer is die 25km natuurlijk niets.
je zou natuurlijk ook gewoon 5 watt en 0,1 watt kunnen opschrijven ipv het over 5000 microwatts te hebben.
Desalniettemin een leuk idee en ik ben benieuwd wat dit voor een nieuwe mogelijkheden gaat bieden. Maar als je alles en nog wat met 0.1 watt opkrikt komt er toch wel weer wat energie verbruik bij. Aan de andere kant als je apparaten nu eindelijk eens allemaal een fatsoenlijke standby modus krijgen dan valt dit in het extra verbruik in het niets.
lezen is een gave die ik kennelijk niet meer bezit
Desalniettemin een leuk idee en ik ben benieuwd wat dit voor een nieuwe mogelijkheden gaat bieden. Maar als je alles en nog wat met 0.1 watt opkrikt komt er toch wel weer wat energie verbruik bij. Aan de andere kant als je apparaten nu eindelijk eens allemaal een fatsoenlijke standby modus krijgen dan valt dit in het extra verbruik in het niets.
lezen is een gave die ik kennelijk niet meer bezit
[Reactie gewijzigd door dragonfly28 op 14 november 2012 14:59]
Micro != milli, dus scheelt een factor duizend. Is dus wel erg weinig energie.
Als je 5 Watt zou opschijven zat je mis: het is 0,005 Watt = 5 milliWatt.
Mooi en aardig, maar welke "things" gaat het hier dan om? Ik hoef dus niet gegevens over mijn gedrag thuis prijs te geven aan deze fransman. Dan gebruik ik liever WiFi-lightbulbs, om het maar zo te zeggen. Hashtag Privacy.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
