EmbeddedRelated.com
Forums

PIC to USB to 802.11g to USB to PC ?

Started by bit eimer November 30, 2004
Hi all,

I'm usually just a lurker.  But now I'm getting interested in doing a link 
from an 'F877 to a PC:

PIC s/w -> UART -> USB (adapter) -> 802.11g (adapter)  --//--> 802.11g 
(adapter) -> USB -> Win XP -> app s/w


Have chosen neither the USB adapter nor the 802.11g adapter yet.  And I'm 
fairly concerned about the potential complexity of USB and 802.11g protocols 
that I will have to implement on the PIC side.

Any one have advice on any part of the above or pointers to some actual 
implementations I could possibly leverage or adapt?

BTW, I'm leaning toward 802.11g rather than Bluetooth in order to achieve 
higher (I think) outdoor range.  Any confirmation of that assumption?

TIA
-- 
...The Bit Eimer     NAR 84054      L0
"My goal in life is to be the kind of person my cat thinks he is"
[remove keinewurst and reverse letters in domain to email me]
--------------------------------------------------------------



Your PIC side of the operation seems to be missing a piece.  I'm not aware 
of any (simple) way to connect a RS232<->USB adapter directly to a WiFi unit 
without involving a USB host such as a PC.  I think you have hinted at your 
own fuzziness to this issue when you mentioned the complexity of USB and 
802.11.  The easiest solution to your problem is to include a USB host so 
that:

PIC ->UART-> USB -> PC HOST -> 802.11 ---//--->


I suppose including a PC in your PIC unit defeats the purpose of the simple 
pic.  I know there are some simple WiFi modules available now for embedded 
low volume stuff such as NetBurner, Digi(something) and probably a few 
others.  Sounds like an interesting project.....


-Jim



"bit eimer" <bit_eimer.keinewurst@ten.xoc> wrote in message 
news:PG8rd.190004$hj.179461@fed1read07...
> Hi all, > > I'm usually just a lurker. But now I'm getting interested in doing a link > from an 'F877 to a PC: > > PIC s/w -> UART -> USB (adapter) -> 802.11g (adapter) --//--> 802.11g > (adapter) -> USB -> Win XP -> app s/w > > > Have chosen neither the USB adapter nor the 802.11g adapter yet. And I'm > fairly concerned about the potential complexity of USB and 802.11g > protocols that I will have to implement on the PIC side. > > Any one have advice on any part of the above or pointers to some actual > implementations I could possibly leverage or adapt? > > BTW, I'm leaning toward 802.11g rather than Bluetooth in order to achieve > higher (I think) outdoor range. Any confirmation of that assumption? > > TIA > -- > ...The Bit Eimer NAR 84054 L0 > "My goal in life is to be the kind of person my cat thinks he is" > [remove keinewurst and reverse letters in domain to email me] > -------------------------------------------------------------- > > >
"Mood" <noone@nowhere.com> wrote in message 
news:S4udnZkyR_Vd0TDcRVn-qg@comcast.com...
> Your PIC side of the operation seems to be missing a piece. I'm not aware > of any (simple) way to connect a RS232<->USB adapter directly to a WiFi > unit without involving a USB host such as a PC. I think you have hinted > at your own fuzziness to this issue when you mentioned the complexity of > USB and 802.11. The easiest solution to your problem is to include a USB > host so that: > > PIC ->UART-> USB -> PC HOST -> 802.11 ---//---> > > > I suppose including a PC in your PIC unit defeats the purpose of the > simple pic. I know there are some simple WiFi modules available now for > embedded low volume stuff such as NetBurner, Digi(something) and probably > a few others. Sounds like an interesting project..... > >
That wasn't just a hint (wrt my fuzziness) - I am mostly a h/w type. I am really vague on what kind of s/w support is required for either the UART-to-USB module or the USB-to-802.11g module. All I really want to do is get packets from the PIC to my application in the PC (about 150 meters away in outdoor terrain), but I'm sure there's all kinds of maintenance functions that must be dealt with. Of course, on the PC side, you not only have the processor to do the work, but also all the canned drivers already done. Is there nothing like that available for the PIC that would ease the task of creating a 802.11g "radio bridge"? I guess in the worst case scenario, I could redesign my remote device to be embedded-PC based, but man that will be overkill vis-vis its primary function. -- ...The Bit Eimer NAR 84054 L0 "My goal in life is to be the kind of person my cat thinks he is" [remove keinewurst and reverse letters in domain to email me] --------------------------------------------------------------
"bit eimer" <bit_eimer.keinewurst@ten.xoc> wrote :

> All I really want to do is get packets from the PIC to my > application in the PC (about 150 meters away in outdoor terrain)
Bluetooth with external antennas works ok for 1-2 miles
> Is there > nothing like that available for the PIC that would ease the task > of creating a 802.11g "radio bridge"?
first of all 802.11g has lower range than 802.11b. Secondly there is no easy way to connect 802.11g adapter to your PIC (there are no rs232-usb adapters in this direction)
> I guess in the worst case scenario, I could redesign my remote > device to be embedded-PC based, but man that will be overkill > vis-vis its primary function.
no need to, just use bluetooth ... or you can use CARDBUS card, but interfacing such a card is a b... not an easy task :), PCCARD is easier, but there are no 802.11g pccards cards. Pozdrawiam. -- RusH // http://randki.o2.pl/profil.php?id_r=352019 Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know -- UNTIL IT'S TOO LATE.
On Tue, 30 Nov 2004 23:49:12 -0700, in article
     <FPdrd.190629$hj.53438@fed1read07>
     bit_eimer.keinewurst@ten.xoc "bit eimer" wrote:
>"Mood" <noone@nowhere.com> wrote in message >news:S4udnZkyR_Vd0TDcRVn-qg@comcast.com... >> Your PIC side of the operation seems to be missing a piece. I'm not aware >> of any (simple) way to connect a RS232<->USB adapter directly to a WiFi >> unit without involving a USB host such as a PC. I think you have hinted >> at your own fuzziness to this issue when you mentioned the complexity of >> USB and 802.11. The easiest solution to your problem is to include a USB >> host so that: >> >> PIC ->UART-> USB -> PC HOST -> 802.11 ---//---> >> >> I suppose including a PC in your PIC unit defeats the purpose of the >> simple pic. I know there are some simple WiFi modules available now for >> embedded low volume stuff such as NetBurner, Digi(something) and probably >> a few others. Sounds like an interesting project..... >> > >That wasn't just a hint (wrt my fuzziness) - I am mostly a h/w type. I am >really vague on what kind of s/w support is required for either the >UART-to-USB module or the USB-to-802.11g module.
There are UART to USB devices that are primarily meant as slave devices to the HOST device the PC (See www.ftdi.com). These are relatively easy because the hard work of USB is done in the host. Doing host side USB in an embedded device can be done but is a lot of work, and normally involves buying stacks for processors other than PIC. Various USB host devices have been mentioned previously in this group. However you also have the headache of 802.11g which normally involves encapsulation of TCP/IP protocol. Some people have put stripped down TCP/IP protocols onto a PIC (see the Lean TCP/IP book). Also note TCP/IP is a bidirectional protocol. The problem is you want to put potentially three heavy layers of software onto a PIC, which I would not dream of doing.
>All I really want to do is get packets from the PIC to my application in the >PC (about 150 meters away in outdoor terrain), but I'm sure there's all >kinds of maintenance functions that must be dealt with.
The first real question is not the mechanics of which 'bits' to use but what is the data transfer? How much data for how long and how often? Your basic system is PIC --> some link --> PC If your data rates are low you could probably use a telemetry band device with potentially a modem encoder chip to get 2400 to 9600 baud, or even buy a radio modem device. Especially if the data direction is unidirectional. For high or very high data rates I would doubt the PIC could keep up. Alternatively get a 802.11g module that is menat for interfacing to an embedded system that deals with the protocols etc.. Meaning you have a more complex micro dedicated to the link. There have been some articles in Circuit Cellar www.circuitcellar.com, about doing that sort of thing.
>Of course, on the PC side, you not only have the processor to do the work, >but also all the canned drivers already done. Is there nothing like that >available for the PIC that would ease the task of creating a 802.11g "radio >bridge"?
802.11g is packet driven but usually an encapsulation of TCP/IP so quite a bit of software.
>I guess in the worst case scenario, I could redesign my remote device to be >embedded-PC based, but man that will be overkill vis-vis its primary >function.
First of all it would be more helpful to know what the data rate and packet sizes are to give a meaningful response. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
"RusH" <logistyka1@pf.pl> wrote in message 
news:Xns95B261B75D97DRusHcomputersystems@193.110.122.97...
> "bit eimer" <bit_eimer.keinewurst@ten.xoc> wrote : > >> All I really want to do is get packets from the PIC to my >> application in the PC (about 150 meters away in outdoor terrain) > > Bluetooth with external antennas works ok for 1-2 miles
Any idea what kind of range one could expect from a bluetooth/USB dongle (without external antenna)?
> >> Is there >> nothing like that available for the PIC that would ease the task >> of creating a 802.11g "radio bridge"? > > first of all 802.11g has lower range than 802.11b.
Hmmm, my research led me to believe that g had more range than b (?). Are you thinking of a, perhaps, which has poor change due to higher freq?
> Secondly there is > no easy way to connect 802.11g adapter to your PIC (there are no > rs232-usb adapters in this direction) > >> I guess in the worst case scenario, I could redesign my remote >> device to be embedded-PC based, but man that will be overkill >> vis-vis its primary function. > > no need to, just use bluetooth ...
Can you recommend specific Bluetooth products that would interface well (or easily) to a PIC?
> or you can use CARDBUS card, but > interfacing such a card is a b... not an easy task :), PCCARD is > easier, but there are no 802.11g pccards cards. >
Thanks for your responses. -- ...The Bit Eimer NAR 84054 L0 "My goal in life is to be the kind of person my cat thinks he is" [remove keinewurst and reverse letters in domain to email me] --------------------------------------------------------------
"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message 
news:20041201.0922.304645snz@pcserv.demon.co.uk...
> On Tue, 30 Nov 2004 23:49:12 -0700, in article
<snip>
> > There are UART to USB devices that are primarily meant as slave devices to > the HOST device the PC (See www.ftdi.com). These are relatively easy > because the hard work of USB is done in the host. Doing host side USB in > an > embedded device can be done but is a lot of work, and normally involves > buying stacks for processors other than PIC. Various USB host devices have > been mentioned previously in this group. > > However you also have the headache of 802.11g which normally involves > encapsulation of TCP/IP protocol. Some people have put stripped down > TCP/IP protocols onto a PIC (see the Lean TCP/IP book). Also note > TCP/IP is a bidirectional protocol. > > The problem is you want to put potentially three heavy layers of software > onto a PIC, which I would not dream of doing.
Thanks for these explanations. Sounds like 802.11 is simply too loaded up with capabilities for me to easily make use of. Others suggest Bluetooth, though I would have all the same questions about that technology.
> >>All I really want to do is get packets from the PIC to my application in >>the >>PC (about 150 meters away in outdoor terrain), but I'm sure there's all >>kinds of maintenance functions that must be dealt with. > > The first real question is not the mechanics of which 'bits' to use but > what is the data transfer? > > How much data for how long and how often?
Actually, the comm is bidirectional. At this stage I would estimate my PC-to-remote data rate requirement at about 30k bits/sec; remote-to-PC at about 5k bits/sec with the possibility of 2 remote devices, each at that rate. Packet sizes vary from 4 bytes up to 20 bytes. At one point I was considering a 900 MHz linksys transciever, but I can't deal with the licensing issue.
> > Alternatively get a 802.11g module that is menat for interfacing to an > embedded system that deals with the protocols etc.. Meaning you have > a more complex micro dedicated to the link. There have been some articles > in Circuit Cellar www.circuitcellar.com, about doing that sort of thing.
Thanks, I'll go looking. <snip>
> First of all it would be more helpful to know what the data rate and > packet > sizes are to give a meaningful response.
See above. Thanks for your response. -- ...The Bit Eimer NAR 84054 L0 "My goal in life is to be the kind of person my cat thinks he is" [remove keinewurst and reverse letters in domain to email me] --------------------------------------------------------------
On Wednesday, in article <U1ord.190858$hj.187576@fed1read07>
     bit_eimer.keinewurst@ten.xoc "bit eimer" wrote:

>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message >news:20041201.0922.304645snz@pcserv.demon.co.uk... >> On Tue, 30 Nov 2004 23:49:12 -0700, in article > ><snip>
................
>> The problem is you want to put potentially three heavy layers of software >> onto a PIC, which I would not dream of doing. > >Thanks for these explanations. Sounds like 802.11 is simply too loaded up >with capabilities for me to easily make use of. Others suggest Bluetooth, >though I would have all the >same questions about that technology.
>> >>>All I really want to do is get packets from the PIC to my application in >>>the >>>PC (about 150 meters away in outdoor terrain), but I'm sure there's all >>>kinds of maintenance functions that must be dealt with. >> >> The first real question is not the mechanics of which 'bits' to use but >> what is the data transfer? >> >> How much data for how long and how often? > >Actually, the comm is bidirectional. At this stage I would estimate my >PC-to-remote data rate requirement at about 30k bits/sec; remote-to-PC at >about 5k bits/sec with the possibility of 2 remote devices, each at that >rate. Packet sizes vary from 4 bytes up to 20 bytes.
5Kbits/sec can be done easily on standard telemetry bands with modem chips (10KHz or 25KHz channel bandwidth most authorities don't like people using n channels witdth for higher rates). However with two remote systems you would need a separate channel (RX/TX) pair for each remote or time slicing issues. 30kbps is difficult on standard license free telemetry bands in most countries. But you might squeeze the data rate into a 25KHz channel with an appropriate modem chip (33kps modems chip POSSIBLY). However even with using 433/459MHz sets you have the issues of cost.
>At one point I was considering a 900 MHz linksys transciever, but I can't >deal with the licensing issue.
Steer clear of anything requiring licensing, but be aware that license exempt bands still need to be dealt with carefully for other users on the same band. This is also true for ANY wireless band you use (bluetooth, 802.11x etc.).
>> Alternatively get a 802.11g module that is menat for interfacing to an >> embedded system that deals with the protocols etc.. Meaning you have >> a more complex micro dedicated to the link. There have been some articles >> in Circuit Cellar www.circuitcellar.com, about doing that sort of thing. > >Thanks, I'll go looking.
It is not a simple requirement. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
"bit eimer" <bit_eimer.keinewurst@ten.xoc> wrote :

> Any idea what kind of range one could expect from a bluetooth/USB > dongle (without external antenna)?
100m max, but it must be class 3 BT dongle (17dbm) external antenna = http://flakey.info/antenna/omni/quarter/ for example, works great, costs pennies
>> first of all 802.11g has lower range than 802.11b. > > > Hmmm, my research led me to believe that g had more range than b > (?)
why ? same frequency, same power, less sensitivity and faster, why on earth would you believe that you can get better range ?
> Are you thinking of a, perhaps, which has poor change due to > higher freq?
a has the same range (approximatelly) as g if you thing about 54Mbit speeds (which are 34Mbit max in reality by the way :P)
> Can you recommend specific Bluetooth products that would interface > well (or easily) to a PIC?
no :) but any RS232 BT would work, I would use one with integrated BT stack, implementing your own stack my take a while (or two) Pozdrawiam. -- RusH // http://randki.o2.pl/profil.php?id_r=352019 Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know -- UNTIL IT'S TOO LATE.
"RusH" <logistyka1@pf.pl> wrote in message 
news:Xns95B2D4A8F5178RusHcomputersystems@193.110.122.97...
> "bit eimer" <bit_eimer.keinewurst@ten.xoc> wrote : >
<snip>
>> Hmmm, my research led me to believe that g had more range than b >> (?) > > why ? same frequency, same power, less sensitivity and faster, why on > earth would you believe that you can get better range ?
Mea culpa, my source (the following article) discusses g vs a, not g vs b. It appears g and b are about equilvalent on range, albeit not on data rate. http://www.commsdesign.com/story/OEG20030114S0008 Thanks again. -- ...The Bit Eimer NAR 84054 L0 "My goal in life is to be the kind of person my cat thinks he is" [remove keinewurst and reverse letters in domain to email me] --------------------------------------------------------------