PaNiC: Du menar alltså att du ska ha överföringen mellan TNC'n och PC eller dyl terminal trådlös?
AndLi: När du talar om RFCOMM så att en bluetooth modul i datorn kan stödja
det där, inte för att det kommer att bli av, men då ångrar jag verkligen
att jag valde bort bluetooth i min nyinköpta laptop, tror det kostade 300Kr extra, men är man dumsnål så är man. Dohh..
Ja, då var man 15st bluetooth-moduler (class 2) rikare
Så klart vi kommer få enheterna att funka braHedis skrev:AndLi> DU kan ju inte köra med en avställd bil(eller hittade du nara på ngt reg-nr?
Nästan så man skulle snickra ihop en RS232 länk om ni får modulerna att fungera bra.
Jag VISST att nån skulle göra en körning på det regnumret... Det är min gamla bil, den är på väg till skroten!
SKulle tagit den tredje volvon istället... iof även den avstäld..Hoppas ingen som skrivit detta X jobb befinner sig här
Titta här, precis det vi vill göra
För mer förvirrad förklaring får man banne mig leta efter... men men..
Ska vi annordna en tävling? Vem får den koden att snurra först?
Titta här, precis det vi vill göra
För mer förvirrad förklaring får man banne mig leta efter... men men..
Ska vi annordna en tävling? Vem får den koden att snurra först?
kikade på akademibokhandeln på universitetet idag, träffade på en elektronikstuderande som visade mig en bok de skulle ha när de hade en bluetooth kurs, boken heter;
"BLUETOOTH 1.1, CONNECT WITHOUT CABLES"
Vad tror ni om den? Bläddrade igenom den snabbt sedan gjorde jag en inpulsbeställning, dom hade den inte på hyllan.
länk till innehåll finns här:
http://www.amazon.com/gp/reader/0130661 ... eader-link
"BLUETOOTH 1.1, CONNECT WITHOUT CABLES"
Vad tror ni om den? Bläddrade igenom den snabbt sedan gjorde jag en inpulsbeställning, dom hade den inte på hyllan.
länk till innehåll finns här:
http://www.amazon.com/gp/reader/0130661 ... eader-link
Jag har inga bra minnen av några bluetooth böcker, mycket för att vi jobbade med 1.1an när den preci kommit, och böckerna var vi hade verkade vara skrivna av folk som bara vill tjäna pengar...
Den bit som är intressant att ha nått utöver specen är defenitivt SDP (Service discovery protocol) vilket är ett härke utan dess like när det kommer till variabla datatypslängder.
Den bit som är intressant att ha nått utöver specen är defenitivt SDP (Service discovery protocol) vilket är ett härke utan dess like när det kommer till variabla datatypslängder.
TJOHO!
De ville inte riktigt prata med varandra först.. Men efter att ha konstaterat att lysdioden på överströmsskyddet blinka som rena discolampan och vridit upp det lite så hittar de varandra. Har inte skickat nån Create Connection än, men det ska nog inte ställa till nått...
Så när jag hittar lite tid att knappa lite till så ska vi nog ha data flytande...
Overhead är bara förnamnet.. När man satt upp länken behövs det en header på 9 BYTE för att kunna skicka iväg data... iof kan man skicka mer än en byte åt gången.. men endå
De ville inte riktigt prata med varandra först.. Men efter att ha konstaterat att lysdioden på överströmsskyddet blinka som rena discolampan och vridit upp det lite så hittar de varandra. Har inte skickat nån Create Connection än, men det ska nog inte ställa till nått...
Så när jag hittar lite tid att knappa lite till så ska vi nog ha data flytande...
Overhead är bara förnamnet.. När man satt upp länken behövs det en header på 9 BYTE för att kunna skicka iväg data... iof kan man skicka mer än en byte åt gången.. men endå
TADA, färdig!!
Så här gör man... Det finns tyvärr ingen kompakt C-kod skriven, eftersom jag kört dem mot PC... Men så fort Renesas dumpar hit utvecklingskitet ska jag se till att få en "embedded version" också.
Man sätter upp den ena som master den andra som slave.
Vi börjar med slaven!
Skicka {0x01, 0x03, 0x0C, 0x00} vilket är HCI_Reset. Fuska inte bort denna, det funkar inte då.
Du ska då få {0x04, 0x0E,0x04, 0x01, 0x03, 0x0C, 0x00} tillbaka.
Man ställer sen in Eventfiltret för att acceptera alla uppkopplingsförsök automatiskt mot enheten. {0x01, 0x05, 0x0C, 0x03, 0x02, 0x00, 0x02} fixar det. Man får då {0x04 0x0E 0x04 0x01 0x05 0x0C 0x00} tillbaka.
Efter detta sätter man upp enheten till att svara på inquiry och page scan.
Ordnast enklast genom att skicka {0x01 0x1A 0x0C 0x01 0x03}, man kommer då få tillbaka {0x04 0x0E 0x04 0x01 0x1A 0x0C 0x00}. Betyder bara OK.
Nu kommer slaven luta sig tillbaka och vänta på bättre tider. Och dessa kommer genom {0x04 0x03 0x0B 0x00 0x01 0x00 0xVV 0xVV 0xVV 0xVV 0xVV 0xVV 0x01 0x00}. Vilket betyder att det nu finns en anslutning till en annan bluetooth enhet med BD_Address VV. Detta är masterns BD_Address.
--------------------------------------------------------------------------------
Detta kommer dock inte hända om man inte gör följande med mastern !!
Skicka {0x01, 0x03, 0x0C, 0x00} vilket är HCI_Reset. Du ska då få {0x04, 0x0E,0x04, 0x01, 0x03, 0x0C, 0x00} tillbaka
Skicka sen {x01,0x01,0x04,0x05,0x33,0x8B,0x9E,0x06,0x00}, vilket är HCI_Inquiry vilket betyder att man ska lyssna efter alla enheter som ligger i "Inquiry Scan enable" mode. Man kommer då direkt få {0x04,0x0F,0x04,0x00,0x01,0x01,0x04}. Detta är bara en CMD okej.
Ligger slaven i "Inquiry_Scan_enable" mode kommer man få
{0x04,0x02,0x0F,0x01,0xXX,0xXX,0xXX,0xXX,0xXX,0xXX,0x01,0x00,0x00,0x04,0x04,0x20,0xYY,0xYY}....
Ur denna behöver vi plocka lite data, de 6 XX kommer innehålla slavens BD_Address. De två YY kommer innehålla clock_offset.
7.68 sekunder efter det att vi skicka HCI_Inquiry kommer det {0x04,0x01,0x01,0x00}, detta säger bara att vi nu slutat scana efter enheter.
Nu ska vi skicka ut en HCI_create_connection ,{0x01,0x05,0x04,0x0D,0xXX,0xXX,0xXX,0xXX,0xXX,0xXX,0x08,0x00,0x00,0x00,0xYY,0xYY,0x00}.
Yepp, de 6 0xXX ska ersättas med den data vi fick i föregående kommando. Detta är som sagt slavens BD_Address och man skulle kunna hårdkoda denna om man alltid kommer använda samma enhet som slav.
De två YY ska också ersättas med tidigare data, denna kan man INTE hårdkoda utan kommer ändras vid varje försök.
Självklart får vi först tillbaka {0x04 0x0F 0x04 0x00 0x01 0x05 0x04} som säger att HCI kommandot var okej.
Sen kommer { 0x04 0x03 0x0B 0x00 0x01 0x00 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0x01 0x00}. vilket berättar att vi nu har en connection till slaven med BD adress XX. (Vilket enligt alla teorier borde vara samma som ovan)
-----------------------------------------------
Vi är nu klara för att skicka data!!!
Vi använder ACL med DM1 paket vilket betyder att vi kan skicka 0-17* bytes vid varje tillfälle. Den teoretiska maxhastigheten åt bägge hållen är då 109 kb/s. Hur gör man då detta? Jo {0x02 0x01 0x20 0xLL 0x00 0x02 0x00 0x00 0x00 0xZZ 0xZZ} Där LL är längden på datan man vill skicka plus 4 och ZZ är datan man vill skicka. Man får inte tillbaka någon data om att man har skickat ut data! På motsatta sidan får man dock följande:
{0x02 0x01 0x20 0xLL 0x00 0x02 0x00 0x00 0x00 0xZZ 0xZZ}
LL ger oss längden på skickad data plus 4 och ZZ är den data vi skickade!
Hela detta förfarandet sker på samma sätt oberoende av vilket håll du skickar datan på!
*Reservation göres för hur mycket data man egentligen kan klämma in i ett DM1 paket... Ska experimentera lite med detta.. Så länge kan ni ju leka med 2 bytes... upp till 10 ska inte vara några prolem.
---------------------------
Det är vad man kan kalla overhead va??
Detta är nog i princip det minsta man kan skicka för att koppla upp en anslutning mellan två enheter. Vi är LÅNGT LÅNGT borta från att ens kunna prata med en RFCOMM enhet... vi är MIL och åter MIL ifrån en certificierad bluetoothenhet... MEN vi har en enhet som glatt kör 8 runt kjell & co 99 kr moduler. Tyvärr har jag inte så långa kablar så jag har inte kunnat kolla räckvidden, men 30 cm funkar fint i alla fall
----------------------------
Förtydligande:
Paket som börjar med 0x01 ska man skicka till bluetoothenheten
Paket som börjar med 0x04 kommer in från bluetoothenheten.
Detta är altså kommunikation med den LOKALA bluetoothenheten.
Paket som innehåller data som ska skickas i luften börjar på 0x02, dessa kommer se precis lika ut när de trillar ner på mottagarens sida. De kommer altså börja på 0x02 oberoende av om det är data vi skickar eller tar emot.
------------------------------
Plan:
Jag måste mixtra mer med ACL datapaketen, jag är rätt övertygad om att de är 4 byte större än vad de behöver vara...
Så här gör man... Det finns tyvärr ingen kompakt C-kod skriven, eftersom jag kört dem mot PC... Men så fort Renesas dumpar hit utvecklingskitet ska jag se till att få en "embedded version" också.
Man sätter upp den ena som master den andra som slave.
Vi börjar med slaven!
Skicka {0x01, 0x03, 0x0C, 0x00} vilket är HCI_Reset. Fuska inte bort denna, det funkar inte då.
Du ska då få {0x04, 0x0E,0x04, 0x01, 0x03, 0x0C, 0x00} tillbaka.
Man ställer sen in Eventfiltret för att acceptera alla uppkopplingsförsök automatiskt mot enheten. {0x01, 0x05, 0x0C, 0x03, 0x02, 0x00, 0x02} fixar det. Man får då {0x04 0x0E 0x04 0x01 0x05 0x0C 0x00} tillbaka.
Efter detta sätter man upp enheten till att svara på inquiry och page scan.
Ordnast enklast genom att skicka {0x01 0x1A 0x0C 0x01 0x03}, man kommer då få tillbaka {0x04 0x0E 0x04 0x01 0x1A 0x0C 0x00}. Betyder bara OK.
Nu kommer slaven luta sig tillbaka och vänta på bättre tider. Och dessa kommer genom {0x04 0x03 0x0B 0x00 0x01 0x00 0xVV 0xVV 0xVV 0xVV 0xVV 0xVV 0x01 0x00}. Vilket betyder att det nu finns en anslutning till en annan bluetooth enhet med BD_Address VV. Detta är masterns BD_Address.
--------------------------------------------------------------------------------
Detta kommer dock inte hända om man inte gör följande med mastern !!
Skicka {0x01, 0x03, 0x0C, 0x00} vilket är HCI_Reset. Du ska då få {0x04, 0x0E,0x04, 0x01, 0x03, 0x0C, 0x00} tillbaka
Skicka sen {x01,0x01,0x04,0x05,0x33,0x8B,0x9E,0x06,0x00}, vilket är HCI_Inquiry vilket betyder att man ska lyssna efter alla enheter som ligger i "Inquiry Scan enable" mode. Man kommer då direkt få {0x04,0x0F,0x04,0x00,0x01,0x01,0x04}. Detta är bara en CMD okej.
Ligger slaven i "Inquiry_Scan_enable" mode kommer man få
{0x04,0x02,0x0F,0x01,0xXX,0xXX,0xXX,0xXX,0xXX,0xXX,0x01,0x00,0x00,0x04,0x04,0x20,0xYY,0xYY}....
Ur denna behöver vi plocka lite data, de 6 XX kommer innehålla slavens BD_Address. De två YY kommer innehålla clock_offset.
7.68 sekunder efter det att vi skicka HCI_Inquiry kommer det {0x04,0x01,0x01,0x00}, detta säger bara att vi nu slutat scana efter enheter.
Nu ska vi skicka ut en HCI_create_connection ,{0x01,0x05,0x04,0x0D,0xXX,0xXX,0xXX,0xXX,0xXX,0xXX,0x08,0x00,0x00,0x00,0xYY,0xYY,0x00}.
Yepp, de 6 0xXX ska ersättas med den data vi fick i föregående kommando. Detta är som sagt slavens BD_Address och man skulle kunna hårdkoda denna om man alltid kommer använda samma enhet som slav.
De två YY ska också ersättas med tidigare data, denna kan man INTE hårdkoda utan kommer ändras vid varje försök.
Självklart får vi först tillbaka {0x04 0x0F 0x04 0x00 0x01 0x05 0x04} som säger att HCI kommandot var okej.
Sen kommer { 0x04 0x03 0x0B 0x00 0x01 0x00 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0x01 0x00}. vilket berättar att vi nu har en connection till slaven med BD adress XX. (Vilket enligt alla teorier borde vara samma som ovan)
-----------------------------------------------
Vi är nu klara för att skicka data!!!
Vi använder ACL med DM1 paket vilket betyder att vi kan skicka 0-17* bytes vid varje tillfälle. Den teoretiska maxhastigheten åt bägge hållen är då 109 kb/s. Hur gör man då detta? Jo {0x02 0x01 0x20 0xLL 0x00 0x02 0x00 0x00 0x00 0xZZ 0xZZ} Där LL är längden på datan man vill skicka plus 4 och ZZ är datan man vill skicka. Man får inte tillbaka någon data om att man har skickat ut data! På motsatta sidan får man dock följande:
{0x02 0x01 0x20 0xLL 0x00 0x02 0x00 0x00 0x00 0xZZ 0xZZ}
LL ger oss längden på skickad data plus 4 och ZZ är den data vi skickade!
Hela detta förfarandet sker på samma sätt oberoende av vilket håll du skickar datan på!
*Reservation göres för hur mycket data man egentligen kan klämma in i ett DM1 paket... Ska experimentera lite med detta.. Så länge kan ni ju leka med 2 bytes... upp till 10 ska inte vara några prolem.
---------------------------
Det är vad man kan kalla overhead va??
Detta är nog i princip det minsta man kan skicka för att koppla upp en anslutning mellan två enheter. Vi är LÅNGT LÅNGT borta från att ens kunna prata med en RFCOMM enhet... vi är MIL och åter MIL ifrån en certificierad bluetoothenhet... MEN vi har en enhet som glatt kör 8 runt kjell & co 99 kr moduler. Tyvärr har jag inte så långa kablar så jag har inte kunnat kolla räckvidden, men 30 cm funkar fint i alla fall
----------------------------
Förtydligande:
Paket som börjar med 0x01 ska man skicka till bluetoothenheten
Paket som börjar med 0x04 kommer in från bluetoothenheten.
Detta är altså kommunikation med den LOKALA bluetoothenheten.
Paket som innehåller data som ska skickas i luften börjar på 0x02, dessa kommer se precis lika ut när de trillar ner på mottagarens sida. De kommer altså börja på 0x02 oberoende av om det är data vi skickar eller tar emot.
------------------------------
Plan:
Jag måste mixtra mer med ACL datapaketen, jag är rätt övertygad om att de är 4 byte större än vad de behöver vara...
Jo, det är väll inte första gången
Du kan skicka ACL data paketen i valfri riktning, så betydelsen MASTER/SLAVE är bara intressant i själva uppkopplingsmomentet.
{0x02 0x01 0x20 0xLL 0xLL 0x02 0x00 0x00 0x00 0xZZ 0xZZ} funkar åt bägge hållen.
Jag får inte riktigt till ACL datan på ett sätt som jag vill.. det enda som funkar är ovanstående, MEN tittar man på HCI specen så säger den bara att {0x02 0x01 0x20 0xLL 0xLL} ska behövas och resten är userdata.
Jag var övertygad om att de 4 bytes var för L2CAP vilket ju ligger över där vi är och leker.. SKUMT är det i alla fall... 0x01 20 är lite skumma bitflaggor som säkert har något med saken att göra...
Så atm är vi låsta vid 2 bytes data per paket, dock är dessa full duplex!
Du kan skicka ACL data paketen i valfri riktning, så betydelsen MASTER/SLAVE är bara intressant i själva uppkopplingsmomentet.
{0x02 0x01 0x20 0xLL 0xLL 0x02 0x00 0x00 0x00 0xZZ 0xZZ} funkar åt bägge hållen.
Jag får inte riktigt till ACL datan på ett sätt som jag vill.. det enda som funkar är ovanstående, MEN tittar man på HCI specen så säger den bara att {0x02 0x01 0x20 0xLL 0xLL} ska behövas och resten är userdata.
Jag var övertygad om att de 4 bytes var för L2CAP vilket ju ligger över där vi är och leker.. SKUMT är det i alla fall... 0x01 20 är lite skumma bitflaggor som säkert har något med saken att göra...
Så atm är vi låsta vid 2 bytes data per paket, dock är dessa full duplex!
