WLAN card to generate pulsed RF?

Hello Nico,

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

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.

Think about the $2-3 class in production cost. A mini-jack is already 
quite cost prohibitive there but the electrical USB funtionality would 
really blow that out of the water. On installed sensors the poor users 
would stand there in the pouring rain, shielding their precious PDAs, 
trying to push the cable into some tiny jack, trying to hold the 
flashlight with the third hand which they don't have...

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:
> Hello Nico,
> 
>>
>>> 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.
>>
> 
> 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.
> 
> Think about the $2-3 class in production cost. A mini-jack is already 
> quite cost prohibitive there but the electrical USB funtionality would 
> really blow that out of the water. On installed sensors the poor users 
> would stand there in the pouring rain, shielding their precious PDAs, 
> trying to push the cable into some tiny jack, trying to hold the 
> flashlight with the third hand which they don't have...


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

-- 

Tauno Voipio, OH2UG
tauno voipio (at) iki fi

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.

When I was more active in ham radio I was astonished what automated code 
readers could do even though that was just beginning in the 70's (back 
when you had to plunk down >$2 for a simple 7474). Most of us could read 
morse code where the signal was a wee change in a garbled soup of 
static. In fact, some scientists claimed that hams could beat Shannon's 
theorem. Don't know about that but those folks who didn't yet master 
code at sufficient speeds built themselves automatic readers and these 
would work down to rather flimsy signal levels. Amazing.

-- 
Regards, Joerg

http://www.analogconsultants.com

Joerg wrote:

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

In the US, the FCC (Part18) allows microwave ovens to use the 2.4 GHz
ISM band, but only because they aren't communication devices. If you
want to use the same frequency for communication,  you fall under Part
15 of the FCC rules which control your modulation, spectral mask,
output power, etc.

Other countries have different regulations which may be more or less
strict.

Hi Joerg,

> Either one needs cables.  ....

What about a mike?  I am not sure they get as cheap as photodiodes,
but some tiny speakers probably will be cheap enough. Then, you can
just use Kansas City modulation [for those who do not have a memory
what this was: 4 periods of 1200 Hz=0,  8 periods of 2400 Hz=1],
modulate
an S3 (or even its 24-bit or 23-bit address variations, I have
implemented
them both but many years ago and now don't remember their respective
S-numbers....). That would take minimal resources, I have managed to
do Kansas City using a 1 MHz 6809 and part of a 6840 timer 20 or
so years ago. Error correction will be limited to checksum only with
S-records, though, which may be an issue, you may have to use some
tougher error checking depending on how dramatic a device failure after
reflashing would be... Then again, I remember my above mentioned
"modem" would not be confused by a phone line signal - voice or
whatever - and would detect all interleaved data frames, very rarely
rejecting some because of checksum error(s).
 The other suggested option - flashing a display window - may also be
good enough, and bringing that down to a binary stream may be somewhat
cheaper than with the mike (the latter would likely need an opamp
and a comparator/schmitt trigger, whereas the photodiode might
take no opamp).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Joerg wrote:
> Hello Nico,
>
> >
> >>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.
> >
>
> 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.
>
> Think about the $2-3 class in production cost. A mini-jack is already
> quite cost prohibitive there but the electrical USB funtionality would
> really blow that out of the water. On installed sensors the poor users
> would stand there in the pouring rain, shielding their precious PDAs,
> trying to push the cable into some tiny jack, trying to hold the
> flashlight with the third hand which they don't have...
> 
> -- 
> Regards, Joerg
> 
> http://www.analogconsultants.com

Joerg wrote:
> Hello Folks,
Hi Joerg.
> 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.
>
> 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.

Not possible.  Modulation is not under software control, and the
firmware is not accessible, at least not in traditional sense.  I
didn't look to see what chipsets are most popular for the software
portion of the adapter, but I'd be suprised if, on typical chip, you
could control modulation at that level.  And if you could, the software
would have to be in firmware, so you'd have to write a program to...

1). Extract firmware from chip
2). Reprogram chipd to do your business
3). Put firmware back.

This process would have to happen in context of a device driver, which
is...ahum...non-trivial, at least on Windows.

Since you only want 2400 baud, why not do the same with UART?  Most
PC's still come with 1 UART, and the microcontrollers have them.

I would make the communication bi-directional, as you would never know
if device received the file intact from PC.

Use BPSK or BFSK modulator/demodulator pair at UART on device and on
PC, powered by UART itself on PC side (could be made very small, about
size of US quarter).  The mark/space scheme you refer to is natural to
the UART.  Use AND gate type collision detection circuit to indicate
collision.  Let DTR activate transmitter, DSR be connected to RSSI
circuit to say when foreign entitity has activated its transmitter.
Set UART mode to 2400,8,n,1 for testing, and crank it up gradually
toward 115,200, while keeping BER within certain accecptable range.
Mititgate errors that get through with software FEC, or, just caculate
CRC-32 on data and have either device retransmit entire frame if there
is a problem.  You will know if there is a problem when, after sending
a frame from the source, you do not receive an acknowledge from the
target.

You can add cryptography on top of this relatively easily if that is a
concern.

Actually, this is not a bad idea for a product.  Your motivational
points about Bluetooth and infrared are valid - Bluetooth is too
complicated in fact.  They did too much and not enough, simultaneously,
if that makes sense.   The only limitation is speed, but at 115,200
bps, that's 10KB/s of useful information, not horrifically bad.

-Le Chaud Lapin-

Hello Arlet,

> 
>>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.
> 
> 
> In the US, the FCC (Part18) allows microwave ovens to use the 2.4 GHz
> ISM band, but only because they aren't communication devices. If you
> want to use the same frequency for communication,  you fall under Part
> 15 of the FCC rules which control your modulation, spectral mask,
> output power, etc.
> 

Well, technically my scheme would not be "communication" because there 
is never a feedback. Could possibly be called, ahem, flash memory cell 
therapy. But I guess this would be stretching the rules a bit far ;-)


> Other countries have different regulations which may be more or less
> strict.
> 

It is even stricter in other countries, especially those with 
communications monopolies. They don't like it when anyone encroaches 
onto their turf. Some even don't allow you to run an optical 
over-the-air or any other link between your house and the direct 
neighbors because they "own" the right of way for anything that involves 
the exchange of information. They do let you have a chat across the 
fence though.

-- 
Regards, Joerg

http://www.analogconsultants.com

Hello Didi,

> 
>>Either one needs cables.  ....
> 
> What about a mike?  I am not sure they get as cheap as photodiodes,
> but some tiny speakers probably will be cheap enough. Then, you can
> just use Kansas City modulation [for those who do not have a memory
> what this was: 4 periods of 1200 Hz=0,  8 periods of 2400 Hz=1],
> modulate
> an S3 (or even its 24-bit or 23-bit address variations, I have
> implemented
> them both but many years ago and now don't remember their respective
> S-numbers....). That would take minimal resources, I have managed to
> do Kansas City using a 1 MHz 6809 and part of a 6840 timer 20 or
> so years ago. Error correction will be limited to checksum only with
> S-records, though, which may be an issue, you may have to use some
> tougher error checking depending on how dramatic a device failure after
> reflashing would be... Then again, I remember my above mentioned
> "modem" would not be confused by a phone line signal - voice or
> whatever - and would detect all interleaved data frames, very rarely
> rejecting some because of checksum error(s).


Audio can annoy others. Many times you have to update firmware in the 
field without moving the device, by bringing the laptop or PDA there. 
The 1200/2400 scheme might be simple enough but to cram that into 0.5k 
or less of bootloader space could be tough.

While the cost of a mike would be negligible thanks to cell phones and 
all that it requires a hole in the target device. That would be a 
serious concern for anything that needs to operate outdoors.


>  The other suggested option - flashing a display window - may also be
> good enough, and bringing that down to a binary stream may be somewhat
> cheaper than with the mike (the latter would likely need an opamp
> and a comparator/schmitt trigger, whereas the photodiode might
> take no opamp).
> 

The advantage is that it doesn't need a hole, just a translucent section 
in the enclosure. The photodiode can, for example, be placed where a 
display is.

-- 
Regards, Joerg

http://www.analogconsultants.com

Le Chaud Lapin wrote:

> Joerg wrote:
> 
>>Hello Folks,
> 
> Hi Joerg.
> 
>>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.
>>
>>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.
> 
> 
> Not possible.  Modulation is not under software control, and the
> firmware is not accessible, at least not in traditional sense.  I
> didn't look to see what chipsets are most popular for the software
> portion of the adapter, but I'd be suprised if, on typical chip, you
> could control modulation at that level.  And if you could, the software
> would have to be in firmware, so you'd have to write a program to...
> 
> 1). Extract firmware from chip
> 2). Reprogram chipd to do your business
> 3). Put firmware back.
> 
> This process would have to happen in context of a device driver, which
> is...ahum...non-trivial, at least on Windows.
> 

That's how it appears to be after Arlet's comments. He mentioned that 
messing with this could be akin to messing with you car's engine 
controller, meaning it could compromise its legality in terms of 
emissions etc.

Also, it would almost have to be a special device driver that could be 
licensed from somewhere when it all goes into production.


> Since you only want 2400 baud, why not do the same with UART?  Most
> PC's still come with 1 UART, and the microcontrollers have them.
> 
> I would make the communication bi-directional, as you would never know
> if device received the file intact from PC.
> 
> Use BPSK or BFSK modulator/demodulator pair at UART on device and on
> PC, powered by UART itself on PC side (could be made very small, about
> size of US quarter).  The mark/space scheme you refer to is natural to
> the UART.  Use AND gate type collision detection circuit to indicate
> collision.  Let DTR activate transmitter, DSR be connected to RSSI
> circuit to say when foreign entitity has activated its transmitter.
> Set UART mode to 2400,8,n,1 for testing, and crank it up gradually
> toward 115,200, while keeping BER within certain accecptable range.
> Mititgate errors that get through with software FEC, or, just caculate
> CRC-32 on data and have either device retransmit entire frame if there
> is a problem.  You will know if there is a problem when, after sending
> a frame from the source, you do not receive an acknowledge from the
> target.
> 

Unfortunately that would require a cable which is what I want to avoid. 
Also, newer laptops do not have a RS232 port anymore. You would need 
either a docking station (impossible in the field) or a separate 
USB-RS232 converter pod (adding even more cabling stuff).


> You can add cryptography on top of this relatively easily if that is a
> concern.
> 
> Actually, this is not a bad idea for a product.  Your motivational
> points about Bluetooth and infrared are valid - Bluetooth is too
> complicated in fact.  They did too much and not enough, simultaneously,
> if that makes sense.   The only limitation is speed, but at 115,200
> bps, that's 10KB/s of useful information, not horrifically bad.
> 

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.

-- 
Regards, Joerg

http://www.analogconsultants.com

Hi Joerg,

> The advantage is that it doesn't need a hole, just a translucent section
> in the enclosure.

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

> The 1200/2400 scheme might be simple enough but to cram that into 0.5k
> or less of bootloader space could be tough.

Oh I am sure it can be done (it has been done by me and other people
some 20 years ago, it should still be doable :-).

 That being said, the previously quoted argumentation holds still
valid,
no hole for the mike with a photodiode.
 On the other hand, you can use anything to record
the Kansas City stream in an MP3 file and distribute this without
having
to mess around with MS hoops etc. You can even use a $50 MP3 player,
put ist earplug near the mike, and not need to carry a laptop, once
you get rid of the hole in the case issue. That would solve also
the problem about annoying other people, not the waterproof
requirement,
though.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Joerg wrote:
> Hello Didi,
>
> >
> >>Either one needs cables.  ....
> >
> > What about a mike?  I am not sure they get as cheap as photodiodes,
> > but some tiny speakers probably will be cheap enough. Then, you can
> > just use Kansas City modulation [for those who do not have a memory
> > what this was: 4 periods of 1200 Hz=0,  8 periods of 2400 Hz=1],
> > modulate
> > an S3 (or even its 24-bit or 23-bit address variations, I have
> > implemented
> > them both but many years ago and now don't remember their respective
> > S-numbers....). That would take minimal resources, I have managed to
> > do Kansas City using a 1 MHz 6809 and part of a 6840 timer 20 or
> > so years ago. Error correction will be limited to checksum only with
> > S-records, though, which may be an issue, you may have to use some
> > tougher error checking depending on how dramatic a device failure after
> > reflashing would be... Then again, I remember my above mentioned
> > "modem" would not be confused by a phone line signal - voice or
> > whatever - and would detect all interleaved data frames, very rarely
> > rejecting some because of checksum error(s).
>
>
> Audio can annoy others. Many times you have to update firmware in the
> field without moving the device, by bringing the laptop or PDA there.
> The 1200/2400 scheme might be simple enough but to cram that into 0.5k
> or less of bootloader space could be tough.
>
> While the cost of a mike would be negligible thanks to cell phones and
> all that it requires a hole in the target device. That would be a
> serious concern for anything that needs to operate outdoors.
>
>
> >  The other suggested option - flashing a display window - may also be
> > good enough, and bringing that down to a binary stream may be somewhat
> > cheaper than with the mike (the latter would likely need an opamp
> > and a comparator/schmitt trigger, whereas the photodiode might
> > take no opamp).
> >
>
> The advantage is that it doesn't need a hole, just a translucent section
> in the enclosure. The photodiode can, for example, be placed where a
> display is.
> 
> -- 
> Regards, Joerg
> 
> http://www.analogconsultants.com