WLAN card to generate pulsed RF?

Le Chaud Lapin wrote:
> Not cool, but people still do it - write to absolute address 0x000B0000
> (monochrome) or 0x0000B800 (color) in DOS applications.
>
> Microsoft knew that it would be futile to tell programmers to stop, so
> on newer versions of Windows, the machine traps write attempts to video
> memory, sends notification to the portion of the operating system that
> controls DOS boxes and DOS video memory (CSRSS.EXE), at which point,
> whatever you were trying to do  is done anyway, but in a non-intrusive
> manner, so the visual results are still the same.


All of which is gone in 64 bit versions of Windows.

On Thu, 26 Oct 2006 21:44:15 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Hello Tauno,
>
>> 
>> Please note that it's fairly easy to detect the presence
>> of a signal in on-off keying. It is much more difficult to
>> reliably detect the absence (off state) of the signal.
>> 
>> This is one of the main reasons that radio teletype communication
>> (RTTY) is using frequency-shift keying instead of on-off keying.
>> The traditional radio keying method is on-off (since G. Marconi).
>> 
>
>I am aware of that. However, in this case we would not have to deal with 
>much noise. The main concern is simplicity of the receiver circuitry. It 
>is quite easy to build an AM detector while FM becomes involved.

In the header you are talking about using WLAN, which suggest that the
2.45 GHZ ISM (=Industrial, Scientific, Medical) band is used.  You
really can not know, if there is little or much noise on a particular
site at a particular time, especially if a wide bandwidth receiver
front end is used as the "simple AM receiver would" suggest. 

Paul
 

Joerg wrote:
[...]
> Bluetooth is indeed too complicated. Speed is not an issue as it can be
> even slower than 2400bd. Much slower if needed. But simplicity is
[...]
> Irda would have been nice but this seems to not really have caught on.
> None of the laptops I have checked had it. And even there it would
[...]

I think you probably could send at least a few dozen bits per second 
via the keyboard num-lock/caps-lock/scroll-lock LED's.  I don't know
what the API is like in Windows; under Linux, see  man setleds
and/or source of same.  setleds works on virtual term's, not xterms.
For xterms, see code at
http://www.lugod.org/mailinglists/archives/vox-tech/2005-07/msg00097.html

-jiw

Hello Paul,

>>
>>>Please note that it's fairly easy to detect the presence
>>>of a signal in on-off keying. It is much more difficult to
>>>reliably detect the absence (off state) of the signal.
>>>
>>>This is one of the main reasons that radio teletype communication
>>>(RTTY) is using frequency-shift keying instead of on-off keying.
>>>The traditional radio keying method is on-off (since G. Marconi).
>>>
>>
>>I am aware of that. However, in this case we would not have to deal with 
>>much noise. The main concern is simplicity of the receiver circuitry. It 
>>is quite easy to build an AM detector while FM becomes involved.
> 
> 
> In the header you are talking about using WLAN, which suggest that the
> 2.45 GHZ ISM (=Industrial, Scientific, Medical) band is used.  You
> really can not know, if there is little or much noise on a particular
> site at a particular time, especially if a wide bandwidth receiver
> front end is used as the "simple AM receiver would" suggest. 
> 

That would be no problem. If there is too much noise the "download ok" 
LED will not signal and the user needs to find a more quite spot. IOW 
away from stuff like microwave ovens or WLAN routers.

-- 
Regards, Joerg

http://www.analogconsultants.com

Hello Dimiter,

> 
>>AFAIR I got over 50bps out of it but the flyback transformer in the
>>monitor was screaming so bad that I stopped.  Don't know what an
>>LCD could do though.
> 
> 
> Probably less. You can forget blinking the cold cathode lamp - the
> invertor is probably  too slow to drive in all cases. I guess assuming
> a 30 Hz refresh rate will be conservative enough, and with some more
> conservativism you go down to the 10 bpS, which I am sure can
> be doubled if you tweak all of the above and some more :-), but
> that will be about all, I guess.
> 

There is no easy access to the CCFL generator. But many LCD can probably 
be cycled at 30 Hz because that is the frame repetition rate of US 
television.

-- 
Regards, Joerg

http://www.analogconsultants.com

robertwessel2@yahoo.com wrote:

> Le Chaud Lapin wrote:
> 
>>Not cool, but people still do it - write to absolute address 0x000B0000
>>(monochrome) or 0x0000B800 (color) in DOS applications.
>>
>>Microsoft knew that it would be futile to tell programmers to stop, so
>>on newer versions of Windows, the machine traps write attempts to video
>>memory, sends notification to the portion of the operating system that
>>controls DOS boxes and DOS video memory (CSRSS.EXE), at which point,
>>whatever you were trying to do  is done anyway, but in a non-intrusive
>>manner, so the visual results are still the same.
> 
> 
> 
> All of which is gone in 64 bit versions of Windows.
> 

You mean the DOS box is gone, too? That would make any 64bit Windows 
version off limits in this office and lab. It would no longer be a 
useful OS.

-- 
Regards, Joerg

http://www.analogconsultants.com

Hello Dimiter,


> Hi folks, sorry for the multiple posted message - I retried it
> a number of times, each time Google timed out and gave me
> a "server error, please do it again in 30 seconds" like message,
> the result being the flood originating here....
> 

That's a problem with most web "newsgroup interfaces". Most are 
unreliable. I had the same thing happen with the IEEE groups and also 
Yahoo groups. Plus numerous others. Ain't nothing like good old usenet 
via a good old newsreader :-)

-- 
Regards, Joerg

http://www.analogconsultants.com

Le Chaud Lapin wrote:

> Joerg wrote:
> 
>>Le Chaud Lapin wrote:
>>Bluetooth is indeed too complicated. Speed is not an issue as it can be
>>even slower than 2400bd. Much slower if needed. But simplicity is
>>paramount here, both with respect to hardware as well as code space for
>>the bootloader on the uC.
>>
>>Irda would have been nice but this seems to not really have caught on.
>>None of the laptops I have checked had it. And even there it would
>>remain to be seen how much mandatory overhead they have crammed into it
>>which would get in the way of simplicity. Irda may be water under the
>>bridge though. If too many laptops in the field don't have it then I
>>cannot use it.
> 
> 
> I agree about simplicity.  I think that there is a market for something
> like what you propose.  Irda was probably the closest, but RF would be
> even better.   Zigbee seemed promising until they followed the path of
> Bluetooth - loading to much poo into the specification.  I downloaded
> the ZigBee specification once.  It's huge.
> 

Then there is the elitist club mentality with some of those standards. 
You have to be a (paying) member of the so-and-so alliance to be in the 
know. This keeps it out of mainstream. IOW if something isn't standard 
on any run-of-the-mills laptop or PDA it just isn't useful enough here.


> There seems like there should be something in between, super simple as
> you say.
> 

Yes!


> If you ever get to the point where you wannt to scratch this itch, I'd
> be inclined to do the software part.   This space is not as well-cooked
> as some people think, IMO.
> 

Well, it seems like there is no RF port available on regular hardware 
that could be used. So maybe I have to design one. 13.56MHz or something 
robust, have to check the legal implications when using it for data 
transfers. With older laptops you always had enough space for PCMCIA 
cards. Newer ones often will only feature USB ports. That means anything 
custom will stick out and, therefore, be prone to breaking off.

I am looking into another wireless project where timing is absolutely 
crucial. Latency needs to be around a millisecond or less on that one. 
If WLAN doesn't perform it's going to be yet another full custom thing. 
Like usual :-(

-- 
Regards, Joerg

http://www.analogconsultants.com

Hello James,

> 
>>Bluetooth is indeed too complicated. Speed is not an issue as it can be
>>even slower than 2400bd. Much slower if needed. But simplicity is
> 
> [...]
> 
>>Irda would have been nice but this seems to not really have caught on.
>>None of the laptops I have checked had it. And even there it would
> 
> [...]
> 
> I think you probably could send at least a few dozen bits per second 
> via the keyboard num-lock/caps-lock/scroll-lock LED's.  I don't know
> what the API is like in Windows; under Linux, see  man setleds
> and/or source of same.  setleds works on virtual term's, not xterms.
> For xterms, see code at
> http://www.lugod.org/mailinglists/archives/vox-tech/2005-07/msg00097.html
> 

Now that's an idea. Except that on some laptops (like the Dell here in 
the office) these LEDs are rather dim.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

> Well, it seems like there is no RF port available on regular hardware
> that could be used. So maybe I have to design one. 13.56MHz or something
> robust, have to check the legal implications when using it for data
> transfers. With older laptops you always had enough space for PCMCIA
> cards. Newer ones often will only feature USB ports. That means anything
> custom will stick out and, therefore, be prone to breaking off.

If you're going to design your own hardware, it may be simpler to make
a standalone device, like a TV remote, with a IR led that can be
pointed at the device to perform a software upgrade.

Of course, this is only cost effective if each single user has a fairly
large number of devices that need to be programmed.