Zgubiłeś klucze? Treasure Tag pomoże Ci je odnaleźć
Autor: Wedelek | źródło: Nokia | 13:32
(11)
Czasami bywa tak, że przez przypadek położymy gdzieś nasze klucze lub portfel i potem mamy problem z ich zlokalizowaniem. Niektórzy ludzie mają z tym szczególny problem, co i rusz gubiąc drobne akcesoria. Jeżeli należysz do tej grupy, to koniecznie powinieneś zainteresować się genialnym gadgetem od Nokii o nazwie Treasure Tag. Jest to niewielki breloczek o wymiarach 30 x 30 x 10 mm i wadze 13 gramów wyposażony w niewielki głośniczek i dwa moduły komunikacji - Bluetooth do łączenia się ze smartfonem, oraz NFC do szybkiego parowania z urządzeniami mobilnymi.
Za zasilanie Treasure Tag odpowiada okrągła, łatwo dostępna bateria CR-2032, która wystarczy na 6 miesięcy pracy. Nie ma zatem konieczności ciągłego ładowania breloczka, co byłoby niezmiernie nużące. Gadget Nokii jest nierozerwalnie związany z dedykowaną mu aplikacją, która czuwa nad tym, byśmy nie rozstawali się z kluczami lub portfelem, do którego przytwierdzony jest Treasure Tag.
Brzmi ciekawie, a jak działa w praktyce? Otóż jeśli pozostawimy gdzieś np. nasze klucze i zaczniemy się od nich oddalać, niewielki głośniczek zacznie emitować dźwięk ostrzegawczy, przywołując nas do porządku. Jeśli go nie usłyszymy, to w sukurs przyjdzie nam telefon, który również zacznie dzwonić/wibrować. A jeśli i tym razem nie zorientujemy się, że czegoś nam brak, to w telefonie zostanie zapamiętana ostatnia znana lokalizacja Treasure Tag, tak byśmy mogli powrócić do miejsca, gdzie zagubiliśmy nasze klucze.
Do sprzedaży trafi kilka wersji kolorystycznych Treasure Tag, a aplikacja poradzi sobie ze śledzeniem kilku takich breloczków. Co ważne w przeciwieństwie np. do Tile, gadget ten współpracuje zarówno z telefonami na bazie Windows Phone, jak i Androida, oraz iOS. Nie jest też przesadnie drogi bo kosztuje 29 dolarów. Nie wiem jak Wam, ale mnie Treasure Tag przekonuje bardziej niż wszystkie smartwatche świata. Brawo Nokia! (PS. Nokia nie płaci mi za pochlebną opinię:) ).
K O M E N T A R Z E
jak nie nokia to (autor: grubas | data: 21/02/14 | godz.: 13:58) giganta z Redmond? ^^
StickNFind itd (autor: RusH | data: 21/02/14 | godz.: 21:55) nic nowego
do tego Wedelek mylisz sie piszac ze w przeciwienstwie do Tile ta Nokia bedzie dzialac z androidem, one WSZYSTKIE dzialaja z androidem ... jesli masz tablet/telefon z Bluetooth LE. Bez BT LE takie tagi sa niemozliwe bo zwykle BT zjada mase energii na podtrzymanie polaczenia. BT LE nie trzyma stalego polaczenia, wysyla tylko pingi od czasu do czasu.
Najprosciej mozna to wytlumaczyc porownujac BT do TCP, oraz BT LE do UDP.
Jest szansa ze Nokia bedzie miec lepsza kontrole jakosci od dupnej kampanii indiegogo, bo Sticknfind bardziej nie dzialaja niz dzialaja (z powodu jakosci produkcji, nie zastosowanej technologii) jak standardowy SZIT z chin http://www.eevblog.com/...luetooth-low-energy-(ble)-tracking-tags/
@RusH (autor: Wedelek | data: 21/02/14 | godz.: 22:33) Nie widziałem jak dotąd żadnego sensownego co by działał na wszystkich trzech wiodących OSach, co nie oznacza, że takiego w ogóle nie ma - tego wszakże nie napisałem. Obecność BT LE lub jego brak to inna kwestia. Z kolei porównanie protokołów warstwy transportowej do BT średnio udane moim zdaniem. Owszem TCP jest połączeniowy, a UDP nie, ale tu chodzi nie o ciągłe połączenie, tylko składanie segmentów w kolejności i kontrolę błędów+ ewentualna retransmisja. Gdybym już używał nomenklatury sieciowej, to bliżej BT do protokołu RIP, który wysyła informacje o sieciach w rozgłoszeniach non stop co jakiś czas, a BT LE do OSPF, który robi to tylko gdy trzeba (nie mówię o Hello). Tylko, że to takie uogólnienie, że hej, więc dajmy lepiej spokój...
Kiszka.... (autor: muerte | data: 22/02/14 | godz.: 09:35) Nic nie przebije breloczka, na którego wystarczyło zagwizdać i odpowiadał :) parę lat temu bardzo modny .... bazarowa myśl techniczna :)
z porownaniem do tcp chodzilo (autor: RusH | data: 22/02/14 | godz.: 13:01)
zupelnie nie czaje porownania z rip i ospf, to zupelnie nie ta warstwa
z porownaniem do tcp chodzilo o to ze raz nawiazane polaczenie BT wymaga ciaglego keep alive + ogromnego stosu z masa zmiennych ktore trzeba stale kontrolowac i odswiezac, protokol wspiera korekcje bledow i retransmicje - tak samo jest z TCP
w przypadku BT LE jest tylko ping i pong, ping z zapytaniem oraz odpowiedz z numerem identyfikacyjnym i doklejonym mu do dupy malym pakietem danych - identycznie jak w UDP
zadnej kolejnosc, zadnych numerow sekwencyjnych, zadnej kontroli bledow ani retransmisji
>Obecność BT LE lub jego brak to inna kwestia
to podstawowa kwestia, google dalo dupy i API dla LE dodali dopiero w 4.3, czego wynikiem sa hackowane na kolanie aplikacje do tagow ktore raz dzialaja a raz nie bo autorzy uzywali nieoficjalnych sdk
@Rush (autor: Wedelek | data: 22/02/14 | godz.: 15:34) ano nie bo protokoły routingu operują na trzeciej warstwie, czyli o oczko niżej. Z RIPem chodziło mi o to, że non stop przesyła masę danych do innych urządzeń (tablice routingu) nawet wtedy, gdy takowa transmisja nie jest potrzebna (standardowo co 30s chyba), a OSPF tylko sprawdza czy sieć działa i wysyła te dane, które potrzeba gdy coś się zmieni.
Różnica polega na tym, że protokoły routingu działają cały czas nie zależnie od tego czy jakieś dane są przesyłane pomiędzy klientami, a TCP/UDP są przywiązane do pojedynczej transmisji. No chyba, że rozumujesz połączenie przez BT jako taką właśnie transmisję non stop.
PS: Doskonale wiem jaka jest różnica pomiędzy "zwykłym" BT a LE:)
Mimo wszystko sam system jako taki obsługuje BT LE, a od której wersji, to jak już pisałem inna rzecz, co nie znaczy, że nie jest to ważna kwestia.
@muerte
To teraz wyobraź sobie, że masz taki brelok i idziesz ulicą mijając kogoś kto sobie gwiżdże. Poza tym takie gadgety jak ten od Nokii to dobry patent na mniej rezolutnych kieszonkowców.
ale BT to warstwa transportowa (autor: RusH | data: 23/02/14 | godz.: 00:03) i NIE MA NIC NIZEJ :)
ty jakos porownujesz warstwe transporotowa do aplikacji wykonujacej jakas czynnosc
no chyba ze uzywasz RIP czy OSPF do przesylania danych pomiedzy komputerami (swoich prywatnych danych ala emaile i www, a nie konfiguracji linkow pomiedzy routerami)
jak udp jest przywiazane do jakiejs pojedynczej transmisji??? pakiet UDP to adres i doklejona do jego dupy paczka z dowolnymi danychmi zapelniona przez ciebie
Pakiet UDP mozna wyslac nawet uzywajac 8 bitowego mikrokontrolera i dwoch pinow GPIO http://www.cesko.host.sk/...DP/IgorPlug-UDP%20(AVR)_eng.htm
BEZ zadnego stosu sieciowego, po prostu wypelnia sie numer odbiorcy i leci w swiat. TAK SAMO dziala BT LE.
w przypadku TCP potrzebny jest stos sieciowy (ciezko taki napisac bez mmu, ja znam tylko contiki). Tak samo w przypadku zwyklego BT potrzebny jest wielowarstwowy stos sieciowy i masa ramu.
propo rip nie wymaga zadnego stosu i jest trywialny w implementacji, ospf za to wymaga masy kodu :) wiec twoje porownanie nie dosc ze nietrafione, to jeszcze jest na odwrot :D
BT vs BT LE nie ma nic wspolnego z tym ile danych i jakie dane wysylasz, dane sa zapakowane wewnatrz pakietow, roznica polega w sposobie obslugi i konstrukcji samych pakietow ktore te dane przesylaja.
Rush (autor: Wedelek | data: 23/02/14 | godz.: 00:59) Ty kompletnie mnie nie rozumiesz. Mnie nie chodzi o to jak to dokładnie działa tylko o ogólną zasadę. Już tłumaczę.
"jak udp jest przywiazane do jakiejs pojedynczej transmisji??? pakiet UDP to adres i doklejona do jego dupy paczka z dowolnymi danychmi zapelniona przez ciebie"
Po pierwsze nie adres, tylko port źródłowy i docelowy (służy do czego innego), a to dopiero jest opakowywane przez kolejne elementy np. protokołu IP z tymi adresami. Po drugie chodziło mi o to, że segmenty są wysyłane podczas komunikacji. Te protokoły same w sobie nie służą do wymiany jakichkolwiek danych umożliwiających podtrzymanie połączenia, chyba że za takowe uznasz potwierdzenia z TCP. One na ogół tylko służą do wymiany danych przesyłanych przez aplikacje. PS: Tylko nie wyskakuj mi tu z ICMP bo to troszkę inna bajka:).
Różnica między BT a BT LE to tak naprawdę to czy non stop mamy komunikację między urządzeniami czy nie. Dla Ciebie ta komunikacja = przesył danych. Dla mnie nie. Rozłączam przesył danych przez aplikacje - np. lokalizację urządzenia, od prostej informacji którą jeden moduł wysyła do drugiego o treści "Jestem".
Stąd też bliżej mi do porównania do protokołów routingu, które zarządzają siecią bez względu na to czy coś się przesyła, czy nie. Z tym porównaniem RIP i OSPF to chodziło mi o sam przesył tablic topologii. Wiadomo, że OSPF jako całość jest bardziej zasobożerny - więcej mocy CPU/RAM potrzeba by tym wszystkim zarządzać. No ale protokoły routingu zostały stworzone z myślą o wielu komputerach połączonych ze sobą, więc stąd tak duże wymagania. Gdyby były tylko dwa, to wtedy te wady też by nikły. Jasne że nadal mamy sprawę implementacji, w końcu RIP to protokół wektora odległości, a OSPF stanu łącza (router ma całą mapę sieci), ale nie o to mi chodziło.
"BT vs BT LE nie ma nic wspolnego z tym ile danych i jakie dane wysylasz, dane sa zapakowane wewnatrz pakietow, roznica polega w sposobie obslugi i konstrukcji samych pakietow ktore te dane przesyłają."
Tu mówisz o protokole sterującym, w który opakowane są dane i który musi mieć adres urządzenia nadawczego i odbiorczego, więc moim zdaniem analogia do TCP/UDP średnio udana. Owszem dane są przesyłane w formie prostych datagramów, ale główna różnica pomiędzy BT a BT LE polega nie na tym jak realizowane jest przesyłanie konkretnych danych, tylko "dogadywanie się" samych modułów.
LoL ale sie rozpisali (autor: grubas | data: 23/02/14 | godz.: 09:51) Może i ambicjonalnie tr
"dogadywanie się" samych modułów (autor: RusH | data: 23/02/14 | godz.: 20:33) w LE nie ma czegos takiego jak dogadywanie sie
tak samo jak w UDP sluchasz calego pasma i odsiewasz to co jest dla ciebie, ewentualnie spamujesz w przestrzen swoje pakiety z nadzieja ze cos je odbierze
@Rush (autor: Wedelek | data: 23/02/14 | godz.: 21:38) no tak, ale mnie chodzi o to, że te dwa moduły muszą co jakiś czas sprawdzać, czy są oba w kontakcie - jeśli nie, to alarm. Zresztą nie ma się co spierać o taką pierdołę. Dla mnie nadal bliżej z porównaniem do protokołów routingu niż TCP/UDP, co nie znaczy, że jest to jakieś trafne porównanie. Tak naprawdę, to przecież samo adresowanie danych (gdzie to ma być podesłane) opiera się na warstwie łącza danych czyli drugiej - fizyczny adres urządzenia docelowego.
My natomiast paplamy o trzeciej i czwartej używając ich jako takie odwołanie porównawcze. Dla Ciebie trafniejsze jest porównanie do UDP/TCP, dla mnie RIP/OSPF, przy czym oboje mocno naginamy rzeczywistość. Proponuję zakończyć tu naszą dysputę.
Żeby nie robić zamieszania mniej zaznajomionym z tym tematem użytkownikom dodam tylko, że tak naprawdę BT LE nie korzysta ani z TCP/UDP, ani tym bardziej do jego implementacji nie używa się OSPF/RIP. Tam są HCI, LLC&AP i SMP. Gdyby ktoś był zainteresowany, to opis jest tu
"tak samo jak w UDP sluchasz calego pasma i odsiewasz to co jest dla ciebie, ewentualnie spamujesz w przestrzen swoje pakiety z nadzieja ze cos je odbierze"
Tylko że UDP w ogóle nie odpowiada za przesyłanie danych, a odpowiednio je oznacza, żeby można było je poprawnie zinterpretować - jak potraktować i do której aplikacji wysłać. Przy użyciu UDP do surowych danych np. żądania DNS, który również korzysta z UDP, doklejasz port docelowy (np. 80) i źródłowy (dynamiczny port aplikacji, która chce te dane), potem jeszcze te dane dzielisz na kawałki i nazywasz segmentami. TCP do tego dokłada jeszcze numerowanie pakietów z segregacją i żądanie ich ponownego przesłania jeśli jeden zaginie. I tyle. Aby to mogło gdzieś trafić konieczna jest enkapsulacja w kolejne protokoły. W przypadku LAN są to IPv4/v6 (dokładamy między innymi adres docelowy i źródłowy IP wykorzystywane podczas routingu), potem Ethernet (dorzucamy MACi - korzystają z tego przełączniki, huby i PCty robiące tablice ARP) i w końcu zamiana na fizyczny sygnał. Oczywiście w zależności od sieci protokoły mogą być inne np. IPSX, Frame Relay, itd. Warto też zauważyć, że do warstwy drugiej stosu ISO/OSI nie ma znaczenia jak przesyłasz dane (jakim medium).
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
