WLAN card to generate pulsed RF?

[Joerg]

Hello Arlet,

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.

 

[David R Brooks]

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.



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?

 

[Joerg]

Hello David,

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.

 

[[email protected]]

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?

 

[Paul Keinanen]

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

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

 

[[email protected]]

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


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.

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.

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.

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.

 

[vasile]

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

 

[Paul Keinanen]

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.

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

 

[Paul Keinanen]

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

 

[Nico Coesel]

Hello Dimiter,

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.

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.

 

[Joerg]

Hello Nico,

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.

Yes, but I'd rather not flick the inverter unless I know exactly how it
is designed. PWM circuits often exhibit some bizarre pathologies and
some lamps might not like this mode either.

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.

Thanks, Nico. That is excellent information. It wouldn't be necessary to
swing between the extremes, a good photo receiver circuit could work
with 25% modulation or even less.

 

[Joerg]

Hello Robert,


[ ... ]

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.

There are some SuperWhatsits that simply cannot be upgraded. Mostly this
happens when a university group that produced excellent work and useful
routines has disbanded. Either because they moved on to something new or
because the professor retired. Academia isn't exactly known to maintain
older things like we do in industry.

Example: "FilterDesign" from Prof.Mildenberger, Wiesbaden, Germany. He
retired and now they even took down his web page. It's a great and
rather indispensable program when you have to design wave digital
filters. The PC switches to full screen DOS to use it. Besides routines
from TI there isn't much else. Those routines are also hardcore DOS,
including one that was released this September.

Bottomline is that if MS drops DOS this business will not upgrade
anymore for a long time and then possibly migrate to another OS. Why
should we upgrade if that reduces productivity?

 

[Joerg]

Hello Vasile,

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)

RSSI is one option. Sometimes the chip that includes it costs too much.
Then I use transistors. But at 2.45GHz a chip might be the better deal.
Still single source, usually, and that is always detrimental from a
business perspective.

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

It's not long distance. The target device would be right next to the laptop.

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

That's why we only design the good stuff

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

It's in the field. Not much around it, plus the field strength two feet
from the laptop will swamp almost any other source. The user is, of
course, not supposed to do this next to a microwave while heating a bag
of Redenbacher's popcorn in there

So, why bootloading over the WIFI ?

Because you will neither need any cables nor any accessory to the
laptop. Wifi is mostly already built in.

 

[Joerg]

Hello Paul,

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.

Absolutely. There needs to be a simple "Re-flash successful" and
"Re-flash failed" signal, nothing else. Plus the option to just leave
the target there for a minute until the "Re-flash successful" light has
finally come on.

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

Good luck with that one. Tried it a few times. You are usually dealing
with huge bureaucracies there. "Speed" can take on a very different meaning.

 

[Alex Gibson]

Hi Joerg,


I agree, this is a significant advantage. Probably the way to go if you
have
to be waterproof - you will still be able to make 10 bpS easily, which
at your
1 - 2 K is still adequate (vs. the 300 bpS of Kansas City).
The main disadvantage I see is the necessity to write some modulation
software for Windows (yuck).

Could always use an ipod screen.
Make a "music video" that has the correct modulation.

Alex

 

[jasen]

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

only if it's audible, I'm sure the speakers in most laptops will go to
22KHz without much effort....

 

[jasen]

Hello Nico,


Either one needs cables. People forget to take them along, they can be
damaged, connectors become dirty, it could be raining or snowing etc.
The audio port on laptops is a 3.5mm audio jack. Those are IMHO rather
unreliable. USB is bulky and expensive.

audio needs a microphone built into the device and a demodulator,
no cabling.

Bye.
Jasen

 

[jasen]

Hello Nico,

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.

yeah!

If the data was encoded in the lengths of the wifi bursts and the gaps
between them were arbitrary (which they neccesarily would be) it might be
able to work.

 

[jasen]

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.

or lcds ...

 

[Joerg]

Hello Jasen,

only if it's audible, I'm sure the speakers in most laptops will go to
22KHz without much effort....

But I am not sure the electronics will. AFAIK 22kHz would be really
close to the Nyquist limit of lower end sound chips. Also, 22kHz could
drive animals such as dogs nuts. We have a little beeper (called
ultrasound but it's really only around 25kHz). While our rottie could
care less because he is quite noise tolerant a terrier that was visiting
almost fell off the stairs when it sounded.