WLAN card to generate pulsed RF?

Hello Arlet,

> 
>>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.
> 

That is one option. However, the new code needs to first reach the 
programming device and nowadays that would be done via a web download. 
This would restrict the available devices to laptops and PDAs. Maybe 
cell phones some day.

Creating a really small RF part isn't a big deal but the USB stuff would 
add bulk. In the days of RS232 we sometimes had the whole enchilada 
inside a connector shell because RS232 is so simple. That's tough to do 
with USB. Anything that sticks out more than 1/2" is prone to break off 
during rough usage.


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

It's not so much about the cost of the programmer but more about 
convenience, reducing the required training to a minimum and utmost 
reliability when used in a very rough environment.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:
> 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 :-(
> 
Nordic Semiconductor (http://www.nvlsi.no/) - and possibly others too - 
do a range of small RF communication chips, some running at 2.4GHz. I 
assume they do comply with the relevant standards.
Maybe you can (a) build a simple sender using one of these, or (b) trick 
a stock wireless card to talk to a Nordic chip?

Hello David,

>
>>
>> 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 :-(
>>
> Nordic Semiconductor (http://www.nvlsi.no/) - and possibly others too - 
> do a range of small RF communication chips, some running at 2.4GHz. I 
> assume they do comply with the relevant standards.
> Maybe you can (a) build a simple sender using one of these, or (b) trick 
> a stock wireless card to talk to a Nordic chip?


Nordic has some nice chips, so do TI, Infineon and others. However, the 
minute you roll your own you have to go through the whole FCC cert from 
scratch. Lots of $$. That's what I really want to avoid.

If I really have to design starting from a blank piece of vellum (yep, 
occasionally using it for first drafts) then I might as well pick a 
lower ISM frequency where things are lower in cost.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:
> 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.


Yep, no DOS or Win16 applications.  Mind you the *DOS* box is gone, not
the (32 bit) command line.  You ought to be able to run one of the VMs
and a 32 bit OS under that of the odd 16 bit application.

What is that you have that continues to require the DOS box that can't
be replaced with Win32 command line code?

On 27 Oct 2006 17:26:02 -0700, "robertwessel2@yahoo.com"
<robertwessel2@yahoo.com> wrote:

>
>Joerg wrote:
>> 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.

There are some hardware issues with the processor running in the AMD
64 bit mode (and compatibles).

>> 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.
>
>Yep, no DOS or Win16 applications.  

While the hardware might not support some instructions on new
hardware, there has been a tradition of emulating the "missing"
instructions in software since the 1960's (IBM).

If Microsoft doesn't want to provide the emulation, there are several
other operating systems that will provide the 8086 emulation in
software :-).
  
>Mind you the *DOS* box is gone, not
>the (32 bit) command line.  

The issue about user interface is a thing that any real OS designer
with any kind of self-respect would not touch even with a long
stick:-). 

IMHO, the user interface should not be a part of any operating system,
just an add-on program. 

>You ought to be able to run one of the VMs
>and a 32 bit OS under that of the odd 16 bit application.

Do you have any positive observations about this ?

While technically this could be done, there are political/commercial
reasons to _not_ providing such emulation.

>What is that you have that continues to require the DOS box that can't
>be replaced with Win32 command line code?

Any program that is supplied as binary (.com or .exe), since the
original company might not exist anymore.

Paul

Paul Keinanen wrote:
> On 27 Oct 2006 17:26:02 -0700, "robertwessel2@yahoo.com"
> <robertwessel2@yahoo.com> wrote:
>
> >
> >Joerg wrote:
> >> 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.
>
> There are some hardware issues with the processor running in the AMD
> 64 bit mode (and compatibles).
>
> >> 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.
> >
> >Yep, no DOS or Win16 applications.
>
> While the hardware might not support some instructions on new
> hardware, there has been a tradition of emulating the "missing"
> instructions in software since the 1960's (IBM).
>
> If Microsoft doesn't want to provide the emulation, there are several
> other operating systems that will provide the 8086 emulation in
> software :-).


The real problem is not an 8086 emulator (in addition to several that
already exist, a basic 8086 emulator would take a few weeks, at most,
to bang out, I/O would be tougher).  Rather it's the OS interface.
While MS-DOS is fairly small, and would be reasonable to emulate, Win16
is a much bigger undertaking.


> >Mind you the *DOS* box is gone, not
> >the (32 bit) command line.
>
> The issue about user interface is a thing that any real OS designer
> with any kind of self-respect would not touch even with a long
> stick:-).
>
> IMHO, the user interface should not be a part of any operating system,
> just an add-on program.


I'm perfect clear on that.  Unfortunately it's quite common to for
users call the Windows command line the "DOS prompt".  Didn't help the
MS called it that themselves in Win9x.  Many people are also unclear
that you can actually have Win32 command line applications.


> >You ought to be able to run one of the VMs
> >and a 32 bit OS under that of the odd 16 bit application.
>
> Do you have any positive observations about this ?
>
> While technically this could be done, there are political/commercial
> reasons to _not_ providing such emulation.


Not personally, but, VMWare 5.5 runs under Win64, and lets you boot 32
bit Windows guests.  VMWare claims WinNT/2K/XP and Win9x support, as
well as Win3.1 and DOS 6 support in their guests.  Never tried anything
other than Win2K/XP through.

MS has stated that their VM implementation will be usable on Win64 to
boot Win32.


> >What is that you have that continues to require the DOS box that can't
> >be replaced with Win32 command line code?
>
> Any program that is supplied as binary (.com or .exe), since the
> original company might not exist anymore.


Certainly that's the usual case (or something homegrown and not moved
to 32 bit).  That's usually the case for one or two point
installations, but the poster I was responding to claimed this made
Win64 unusable for their entire office and lab.

So the question remains, why can't they move to a Win32 app?  In many
cases the reason is either inertia (haven't upgrade my copy of
SuperWhatsit since 1994) or misconception (Command Prompt = DOS Box),
in which case it's not a real limitation.

Joerg wrote:
>
> 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.


  This is perfect possible with any transciever having an analog RSSI
output (like MAX2820 to MAX2829 or a digital RSSI output like Chipcon
devices)  *IF* woud be used in a clean RF environement (near and on the
2.41-2.48Ghz ISM band there are a lot of licensed and unlicensed
activities: WIBRO, WIMAX, WIFI, WIBREE, Bluethooth, Zigbee, etc)

>
> 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.


Again, only IF the executable will be received clean and the CRC will
be OK.
Much doubt will be like this on long distance.


>
> 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.


Ohh, software... without a good hardware means zero.


> 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.

Like someone said, a microwave owen or a Zigbee transmitter  very close
to your receiver :)

>
> 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.
> 
  So, why bootloading over the WIFI ?

greetings,
Vasile

On 27 Oct 2006 22:08:46 -0700, robertwessel2@yahoo.com wrote:

>
>Paul Keinanen wrote:
>> On 27 Oct 2006 17:26:02 -0700, "robertwessel2@yahoo.com"
>> <robertwessel2@yahoo.com> wrote:
>>
>> >
>> >Joerg wrote:
>> >> 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.
>> >
>> >Yep, no DOS or Win16 applications.
>>
>> While the hardware might not support some instructions on new
>> hardware, there has been a tradition of emulating the "missing"
>> instructions in software since the 1960's (IBM).
>>
>> If Microsoft doesn't want to provide the emulation, there are several
>> other operating systems that will provide the 8086 emulation in
>> software :-).
>
>
>The real problem is not an 8086 emulator (in addition to several that
>already exist, a basic 8086 emulator would take a few weeks, at most,
>to bang out, I/O would be tougher).  Rather it's the OS interface.
>While MS-DOS is fairly small, and would be reasonable to emulate, Win16
>is a much bigger undertaking.

At least most older users would still have the Win 3.x license, so
there should not even be a legal reason for not running Win 3.x in a
virtual machine.

>> >Mind you the *DOS* box is gone, not
>> >the (32 bit) command line.
>>
>> The issue about user interface is a thing that any real OS designer
>> with any kind of self-respect would not touch even with a long
>> stick:-).
>>
>> IMHO, the user interface should not be a part of any operating system,
>> just an add-on program.

I am referring to the user interface in a broader sense (not just a
command line interpreter CLI), since for example Win NT 3.51
Progman.exe would typically start a new application with the ordinary
CreateProcess() call used to start other programs.

>I'm perfect clear on that.  Unfortunately it's quite common to for
>users call the Windows command line the "DOS prompt".  Didn't help the
>MS called it that themselves in Win9x.  

I have never used Win9x operating systems, but on the WinNT side,
since NT 3.x days the command interpreter window has been referenced
as "console window".

>Many people are also unclear
>that you can actually have Win32 command line applications.

That is their problem.


Paul

On 27 Oct 2006 22:45:32 -0700, "vasile" <piclist9@gmail.com> wrote:

>
>Joerg wrote:
>>
>> 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.
>
>
>  This is perfect possible with any transciever having an analog RSSI
>output (like MAX2820 to MAX2829 or a digital RSSI output like Chipcon
>devices)  *IF* woud be used in a clean RF environement (near and on the
>2.41-2.48Ghz ISM band there are a lot of licensed and unlicensed
>activities: WIBRO, WIMAX, WIFI, WIBREE, Bluethooth, Zigbee, etc)

Yes indeed.

Any application running in the license exempt bands that also are ISM
bands, such as 13.5 Mhz, 27 MHz, 2.45 MHz (and 900 MHz in the US)
should be designed to be idiot proof. Anything can happen on these
bands.

When using applications running on a licensed frequency, you can
always request the licensing authority to handle the interference
problems.

Paul

Joerg <notthisjoergsch@removethispacbell.net> wrote:

>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

The inverter can be driven on/off at several 10s of Hz, but it takes
several 10s of ms for the driver to reach full output.

>> 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.

That depends entirely on the speed of the LCD screen. Latency of TFT
lies somewhere between 4 to 10ms. The latency number specified for TFT
screens is the sum of the time required to go from black to white and
from white to black. A screen rated for 8ms may have a white->black
time of 2ms and a black->white time of 6ms.

With OpenGL it is possible to update the screen buffer on vertical
blanks. Since almost every TFT screen is driven at 50Hz, you could
make the display flash completely at a rate of 25Hz (40ms period). A
good Windows programmer should be able to program something like this
in a few days.

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