WLAN card to generate pulsed RF?

Hello Folks,

This would address both electronics and embedded engineers. Is there a 
method to coax a regular built-in WLAN port on a laptop (or a WLAN card) 
  into piping out a simple and slow on/off data stream? Without 
protocols and all that, and without waiting for any receive packets.

The reason behind this idea: Assume you have a small uC based product. 
Every once in a while it needs to be updated with new firmware. The 
usual scenario is to provide a USB connection or an infrared port. Both 
are cumbersome. USB adds a lot of cost to the target device and the 
cable gets in the way (oh drat, forgot to pack the cable...). Infrared 
is tough because many laptops simply don't have it. However, nearly all 
of them have built-in wireless these days.

The scenario I imagine is this:

a. The target device is equipped with a simple and not very sensitive 
receiver and AM detector for 2.45GHz ISM (WLAN range). This runs into a 
comparator port of the uC. Much simpler than Bluetooth and all that, 
plus lots of laptops don't have Bluetooth.

b. The user receives one executable file containing the new firmware, 
code to initialize the WLAN port and code to run that port in a simple 
(but legal) AM on/off mode. This executable would now be started.

c. The user is instructed to press a magic button combination which sets 
the target device into re-flash mode, upon which it waits for a data 
stream from the WLAN card.

d. The user must place the target device within a couple of feet of the 
WLAN equipped laptop until a LED flashes, indicating that it has 
detected the presence of a sufficiently strong pulsed carrier somewhere 
around 2.45GHz.

e. A serial on/off data stream is constantly pouring out of the WLAN 
port of the PC. A bootloader in the target device looks for a passcode 
and when it finds that it loads the data stream that follows.

f. The target device stops at an end-of-file token, does sufficient 
integrity checking on what it has received and then leaves re-flash 
mode. It's now ready to use with the new firmware.

Any idea on how to get point "b." done? Tried Google but pulled numerous 
blanks. Then again, I am not a software guy so maybe I am looking in the 
wrong places.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

> This would address both electronics and embedded engineers. Is there a
> method to coax a regular built-in WLAN port on a laptop (or a WLAN card)
>   into piping out a simple and slow on/off data stream? Without
> protocols and all that, and without waiting for any receive packets.
>
> The reason behind this idea: Assume you have a small uC based product.
> Every once in a while it needs to be updated with new firmware. The
> usual scenario is to provide a USB connection or an infrared port. Both
> are cumbersome. USB adds a lot of cost to the target device and the
> cable gets in the way (oh drat, forgot to pack the cable...). Infrared
> is tough because many laptops simply don't have it. However, nearly all
> of them have built-in wireless these days.
>
> The scenario I imagine is this:
>
> a. The target device is equipped with a simple and not very sensitive
> receiver and AM detector for 2.45GHz ISM (WLAN range). This runs into a
> comparator port of the uC. Much simpler than Bluetooth and all that,
> plus lots of laptops don't have Bluetooth.
>
> b. The user receives one executable file containing the new firmware,
> code to initialize the WLAN port and code to run that port in a simple
> (but legal) AM on/off mode. This executable would now be started.
>
> c. The user is instructed to press a magic button combination which sets
> the target device into re-flash mode, upon which it waits for a data
> stream from the WLAN card.
>
> d. The user must place the target device within a couple of feet of the
> WLAN equipped laptop until a LED flashes, indicating that it has
> detected the presence of a sufficiently strong pulsed carrier somewhere
> around 2.45GHz.
>
> e. A serial on/off data stream is constantly pouring out of the WLAN
> port of the PC. A bootloader in the target device looks for a passcode
> and when it finds that it loads the data stream that follows.
>
> f. The target device stops at an end-of-file token, does sufficient
> integrity checking on what it has received and then leaves re-flash
> mode. It's now ready to use with the new firmware.
>
> Any idea on how to get point "b." done? Tried Google but pulled numerous
> blanks. Then again, I am not a software guy so maybe I am looking in the
> wrong places.

If you want to stay within the normal WLAN protocols, it's possible to
tell the WLAN card to set up an IBSS or Ad-Hoc network (it can do that
without other WLAN cards present). Then you can send broadcast packets,
and the WLAN card will forward them on the 2.45 GHz band. Broadcast
packets won't need any replies. Be prepared that the OS network stack
will also send out broadcast packets over the same network interface by
default.

For closer control you need access to the firmware of the device, which
isn't going to be available typically. In a hypothetical situation
where you had access to such firmware, you may be able to turn the
transmitter on and off much quicker (although such behaviour may fall
outside the regulatory limits)

Do you intend to send the entire data stream as AM on/off signals ? In
that case, the IBSS method won't be very practical, since each packet
contains considerable overhead. A few thousand packets/second would be
the upper limit. If that's enough, you could conceivable send shorter
and longer broadcast packets to signify 0's and 1's. Keep in mind that
both rate and gaps may vary beyond your control.

Of course, WLAN is quite ubiquitous, so be prepared for plenty of
interference anywhere you are. An error correcting code may be
necessary. Even if you keep your device real close, and only watch a
strong signal, a standard WLAN card will be much more sensitive, and
keep quiet when it hears other traffic, potentially causing big gaps in
its own transmission.

Hello Arlet,

> 
>>This would address both electronics and embedded engineers. Is there a
>>method to coax a regular built-in WLAN port on a laptop (or a WLAN card)
>>  into piping out a simple and slow on/off data stream? Without
>>protocols and all that, and without waiting for any receive packets.
>>
>>The reason behind this idea: Assume you have a small uC based product.
>>Every once in a while it needs to be updated with new firmware. The
>>usual scenario is to provide a USB connection or an infrared port. Both
>>are cumbersome. USB adds a lot of cost to the target device and the
>>cable gets in the way (oh drat, forgot to pack the cable...). Infrared
>>is tough because many laptops simply don't have it. However, nearly all
>>of them have built-in wireless these days.
>>
>>The scenario I imagine is this:
>>
>>a. The target device is equipped with a simple and not very sensitive
>>receiver and AM detector for 2.45GHz ISM (WLAN range). This runs into a
>>comparator port of the uC. Much simpler than Bluetooth and all that,
>>plus lots of laptops don't have Bluetooth.
>>
>>b. The user receives one executable file containing the new firmware,
>>code to initialize the WLAN port and code to run that port in a simple
>>(but legal) AM on/off mode. This executable would now be started.
>>
>>c. The user is instructed to press a magic button combination which sets
>>the target device into re-flash mode, upon which it waits for a data
>>stream from the WLAN card.
>>
>>d. The user must place the target device within a couple of feet of the
>>WLAN equipped laptop until a LED flashes, indicating that it has
>>detected the presence of a sufficiently strong pulsed carrier somewhere
>>around 2.45GHz.
>>
>>e. A serial on/off data stream is constantly pouring out of the WLAN
>>port of the PC. A bootloader in the target device looks for a passcode
>>and when it finds that it loads the data stream that follows.
>>
>>f. The target device stops at an end-of-file token, does sufficient
>>integrity checking on what it has received and then leaves re-flash
>>mode. It's now ready to use with the new firmware.
>>
>>Any idea on how to get point "b." done? Tried Google but pulled numerous
>>blanks. Then again, I am not a software guy so maybe I am looking in the
>>wrong places.
> 
> 
> If you want to stay within the normal WLAN protocols, it's possible to
> tell the WLAN card to set up an IBSS or Ad-Hoc network (it can do that
> without other WLAN cards present). Then you can send broadcast packets,
> and the WLAN card will forward them on the 2.45 GHz band. Broadcast
> packets won't need any replies. Be prepared that the OS network stack
> will also send out broadcast packets over the same network interface by
> default.
> 

Thanks for the pointer. Now I'll know what expressions to look for.


> For closer control you need access to the firmware of the device, which
> isn't going to be available typically. In a hypothetical situation
> where you had access to such firmware, you may be able to turn the
> transmitter on and off much quicker (although such behaviour may fall
> outside the regulatory limits)
> 

"... isn't going to be typically available" is exactly what I was 
thinking after finding almost nothing on the web :-(


> Do you intend to send the entire data stream as AM on/off signals ? In
> that case, the IBSS method won't be very practical, since each packet
> contains considerable overhead. A few thousand packets/second would be
> the upper limit. If that's enough, you could conceivable send shorter
> and longer broadcast packets to signify 0's and 1's. Keep in mind that
> both rate and gaps may vary beyond your control.
> 

Yes, the entire stream would be AM on/off. Rate changes and gaps would 
render it quite useless though since a small uC cannot contain much 
intelligence in the bootloader. Those bootloaders typically have to fit 
into 256 or 512 byte sectors. Not a whole lot.


> Of course, WLAN is quite ubiquitous, so be prepared for plenty of
> interference anywhere you are. An error correcting code may be
> necessary. Even if you keep your device real close, and only watch a
> strong signal, a standard WLAN card will be much more sensitive, and
> keep quiet when it hears other traffic, potentially causing big gaps in
> its own transmission.
> 

Well, that's exactly the point. I'd have to uncouple the WLAN card from 
it's habit of halting whenever something else talks. At least for a few 
seconds. However, that might sometimes not be permitted by the 
authorities. A way around that would be burst transmissions as long as 
it is legal. Net data rates as low as 2400bps would be quite acceptable. 
Even less if needed since the user could place the device on the table 
and then go do something else.

The only other option I could think of (and I have done that before) is 
to provide a photodiode and let the LCD screen flash. However, that is 
really slow and can annoy others who have to work close to that laptop.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

> Well, that's exactly the point. I'd have to uncouple the WLAN card from
> it's habit of halting whenever something else talks. At least for a few
> seconds. However, that might sometimes not be permitted by the
> authorities. A way around that would be burst transmissions as long as
> it is legal. Net data rates as low as 2400bps would be quite acceptable.
> Even less if needed since the user could place the device on the table
> and then go do something else

Yes, and the danger of interfering with regulation or the protocol is
one of the reasons WLAN vendors are not going to let you touch the
firmware.

> The only other option I could think of (and I have done that before) is
> to provide a photodiode and let the LCD screen flash. However, that is
> really slow and can annoy others who have to work close to that laptop.

If you get the photodiode close enough, you only need to flash a small
area, or maybe you can alternate between colors that appear to have
similar brightness for human perception, but still offer enough
contrast for the photodiode.

Hello Arlet,

> 
>>Well, that's exactly the point. I'd have to uncouple the WLAN card from
>>it's habit of halting whenever something else talks. At least for a few
>>seconds. However, that might sometimes not be permitted by the
>>authorities. A way around that would be burst transmissions as long as
>>it is legal. Net data rates as low as 2400bps would be quite acceptable.
>>Even less if needed since the user could place the device on the table
>>and then go do something else
> 
> 
> Yes, and the danger of interfering with regulation or the protocol is
> one of the reasons WLAN vendors are not going to let you touch the
> firmware.
> 

That's what I am afraid might stop this approach dead in the tracks. 
Unless it could at least be (legally) brought into a burst more where 
each burst is interpreted as a bit.

> 
>>The only other option I could think of (and I have done that before) is
>>to provide a photodiode and let the LCD screen flash. However, that is
>>really slow and can annoy others who have to work close to that laptop.
> 
> 
> If you get the photodiode close enough, you only need to flash a small
> area, or maybe you can alternate between colors that appear to have
> similar brightness for human perception, but still offer enough
> contrast for the photodiode.
> 

That would require filtering but could be done. At least it's better 
than using audio because that would be really annoying to others.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

> That's what I am afraid might stop this approach dead in the tracks.
> Unless it could at least be (legally) brought into a burst more where
> each burst is interpreted as a bit.

Within the 802.11 protocol as implemented by these WLAN cards, there's
no legal burst mode that would be useful for your purpose. I've been
involved in the design of WLAN firmware, and on the devices I'm
familiar with it would require a firmware change to get detailed
control over the transmitter function. Some vendors or devices may have
a hidden test mode for low-level transmitter tests, but I expect those
to be undocumented at best.

Joerg <notthisjoergsch@removethispacbell.net> wrote:

>Hello Folks,
>
>This would address both electronics and embedded engineers. Is there a 
>method to coax a regular built-in WLAN port on a laptop (or a WLAN card) 
>  into piping out a simple and slow on/off data stream? Without 
>protocols and all that, and without waiting for any receive packets.
>
>The reason behind this idea: Assume you have a small uC based product. 
>Every once in a while it needs to be updated with new firmware. The 
>usual scenario is to provide a USB connection or an infrared port. Both 
>are cumbersome. USB adds a lot of cost to the target device and the 
>cable gets in the way (oh drat, forgot to pack the cable...). Infrared 
>is tough because many laptops simply don't have it. However, nearly all 
>of them have built-in wireless these days.
>
>The scenario I imagine is this:
>
>a. The target device is equipped with a simple and not very sensitive 
>receiver and AM detector for 2.45GHz ISM (WLAN range). This runs into a 
>comparator port of the uC. Much simpler than Bluetooth and all that, 
>plus lots of laptops don't have Bluetooth.

That won't work reliable because WLAN frequencies are shared amongst
different networks. Consider a frequency being an ethernet cable
shared with your neighbours. If your neighbours are transmitting on
the cable, you can't transmit. If you re-program your WLAN adapter to
output other patterns that usual, you'll be building a WLAN jammer.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Hello Arlet,

> 
>>That's what I am afraid might stop this approach dead in the tracks.
>>Unless it could at least be (legally) brought into a burst more where
>>each burst is interpreted as a bit.
> 
> Within the 802.11 protocol as implemented by these WLAN cards, there's
> no legal burst mode that would be useful for your purpose. I've been
> involved in the design of WLAN firmware, and on the devices I'm
> familiar with it would require a firmware change to get detailed
> control over the transmitter function. Some vendors or devices may have
> a hidden test mode for low-level transmitter tests, but I expect those
> to be undocumented at best.
> 

That would make this a no-go. Especially when, as you wrote, a firmware 
change would be the only way to cause a WLAN port to do CW. I guess that 
enabling/disabling WLAN couldn't be done fast enough to effect a 
meaningful data rate either.

It surprises me though that it wouldn't be legal at least around 
2.450GHz. That's where microwave ovens blast off hundreds of watts, some 
of which leak out. They don't adhere to any modulation scheme, it's more 
or less filtered DC plus 60/120Hz drooping picket fences to each side (a 
whole lot wider for the ones with switcher supplies). On the spectrum 
analyzer these can swamp whatever WLAN is in the room.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg <notthisjoergsch@removethispacbell.net> wrote:

>
>The only other option I could think of (and I have done that before) is 
>to provide a photodiode and let the LCD screen flash. However, that is 
>really slow and can annoy others who have to work close to that laptop.

Why not use the audio output of the laptop? Every laptop has one and
it is very easy to program. If you get really nifty, you can
distribute your firmware as an mp3 file.

Still, I think USB really is the sensible way to go for these sort of
things. USB to serial adapter chips are commonly available and small
(like the CP2101). Cabling is not an issue if you use standard
(miniature) USB sockets. Drivers can be made available from your
website.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Hello Nico,

>>
>>This would address both electronics and embedded engineers. Is there a 
>>method to coax a regular built-in WLAN port on a laptop (or a WLAN card) 
>> into piping out a simple and slow on/off data stream? Without 
>>protocols and all that, and without waiting for any receive packets.
>>
>>The reason behind this idea: Assume you have a small uC based product. 
>>Every once in a while it needs to be updated with new firmware. The 
>>usual scenario is to provide a USB connection or an infrared port. Both 
>>are cumbersome. USB adds a lot of cost to the target device and the 
>>cable gets in the way (oh drat, forgot to pack the cable...). Infrared 
>>is tough because many laptops simply don't have it. However, nearly all 
>>of them have built-in wireless these days.
>>
>>The scenario I imagine is this:
>>
>>a. The target device is equipped with a simple and not very sensitive 
>>receiver and AM detector for 2.45GHz ISM (WLAN range). This runs into a 
>>comparator port of the uC. Much simpler than Bluetooth and all that, 
>>plus lots of laptops don't have Bluetooth.
> 
> 
> That won't work reliable because WLAN frequencies are shared amongst
> different networks. Consider a frequency being an ethernet cable
> shared with your neighbours. If your neighbours are transmitting on
> the cable, you can't transmit. ...


Not really since the field strength two feet from a laptop will be 
vastly higher than even a router in the next room. Unless it happens to 
be right behind the wall but then the user would know that or have to be 
educated about stuff like that. For an AM protocol to work quite well 
you wouldn't need much more than 6dB of SNR above other WLAN participants.


>               ... If you re-program your WLAN adapter to
> output other patterns that usual, you'll be building a WLAN jammer.
> 

Definitely not. Even if legal it would be unethical. First, there are 
about ten WLAN "channels" in most countries and you'd only block one. 
Second, you don't even have to block that one channel. The card could 
send really brief bursts and the duty cycle could be kept to a few 
percent. Then you would be less of a burden to other users than a kid 
that downloads the latest and greatest iTunes song or YouTube movie. 
Whatever they find funny about those movies...

Keep in mind that the typical uC in a small target device contains only 
1-2k of code. It doesn't take a whole lot of channel capacity to scoot 
that over. You could be done in under one second if needed. That's 
hardly a jammer ;-)

-- 
Regards, Joerg

http://www.analogconsultants.com