Discussion:
WLAN card to generate pulsed RF?
(too old to reply)
Joerg
2006-10-26 18:04:44 UTC
Permalink
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
Arlet
2006-10-26 18:36:35 UTC
Permalink
Post by Joerg
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.
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.
Joerg
2006-10-26 19:02:58 UTC
Permalink
Hello Arlet,
Post by Arlet
Post by Joerg
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.
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.
Post by Arlet
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 :-(
Post by Arlet
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.
Post by Arlet
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
Arlet
2006-10-26 19:24:14 UTC
Permalink
Post by Joerg
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.
Post by Joerg
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.
Joerg
2006-10-26 20:01:56 UTC
Permalink
Hello Arlet,
Post by Arlet
Post by Joerg
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.
Post by Arlet
Post by Joerg
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
Arlet
2006-10-26 20:19:03 UTC
Permalink
Post by Joerg
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
2006-10-26 20:32:46 UTC
Permalink
Hello Arlet,
Post by Arlet
Post by Joerg
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
Arlet
2006-10-26 21:45:05 UTC
Permalink
Post by Joerg
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.
Joerg
2006-10-26 21:54:04 UTC
Permalink
Hello Arlet,
Post by Arlet
Post by Joerg
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 ;-)
Post by Arlet
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
jasen
2006-10-29 09:57:09 UTC
Permalink
Post by Joerg
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....
--
Bye.
Jasen
Joerg
2006-10-29 17:18:29 UTC
Permalink
Hello Jasen,
Post by jasen
Post by Joerg
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....
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.
--
Regards, Joerg

http://www.analogconsultants.com
Terry Given
2006-10-30 03:18:39 UTC
Permalink
Post by Joerg
Hello Arlet,
Post by Arlet
Post by Joerg
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.
Post by Arlet
Post by Joerg
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.
Hi Joerg,

why not take a leaf out of teenagers book of phone tricks, and use 20kHz
audio...

Cheers
Terry
Joerg
2006-10-30 22:21:38 UTC
Permalink
Hello Terry,
Post by Didi
Post by Joerg
Post by Arlet
Post by Joerg
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.
Post by Arlet
Post by Joerg
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.
Hi Joerg,
why not take a leaf out of teenagers book of phone tricks, and use 20kHz
audio...
Ask our shepherd-mix for her opinion about 20kHz ;-)

Whenever I do high-frequency audio stuff or PWM in the lab and a ferrite
core gets a bit loose she dashes off to the other end of the building.
The rottie-mix keeps snoring away under a table.
--
Regards, Joerg

http://www.analogconsultants.com
Terry Given
2006-10-31 08:02:58 UTC
Permalink
Hi Joerg,
Post by Joerg
Hello Terry,
Post by Didi
Post by Joerg
Post by Arlet
Post by Joerg
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.
Post by Arlet
Post by Joerg
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.
Hi Joerg,
why not take a leaf out of teenagers book of phone tricks, and use
20kHz audio...
Ask our shepherd-mix for her opinion about 20kHz ;-)
Whenever I do high-frequency audio stuff or PWM in the lab and a ferrite
core gets a bit loose she dashes off to the other end of the building.
The rottie-mix keeps snoring away under a table.
LOL :)

can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?

Cheers
Terry
Joerg
2006-10-31 15:31:44 UTC
Permalink
Hello Terry,
Post by Terry Given
Post by Joerg
Post by Terry Given
why not take a leaf out of teenagers book of phone tricks, and use
20kHz audio...
Ask our shepherd-mix for her opinion about 20kHz ;-)
Whenever I do high-frequency audio stuff or PWM in the lab and a
ferrite core gets a bit loose she dashes off to the other end of the
building. The rottie-mix keeps snoring away under a table.
LOL :)
can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?
Probably. But that would require some patience on the part of the folks
that have to do the firmware updates in the field. And who knows, maybe
that would bother the whales in the oceans :-)
--
Regards, Joerg

http://www.analogconsultants.com
Wim Ton
2006-11-14 21:08:41 UTC
Permalink
Post by Terry Given
can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?
Cheers
Terry
Sounds like NFC. That will give you at least 100 kb/s

Wim
Terry Given
2006-11-15 00:34:20 UTC
Permalink
Post by Wim Ton
Post by Terry Given
can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?
Cheers
Terry
Sounds like NFC. That will give you at least 100 kb/s
Wim
que? NFC?!

Cheers
Terry
Wim Ton
2006-11-15 18:18:22 UTC
Permalink
Post by Terry Given
Post by Wim Ton
Post by Terry Given
can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?
Cheers
Terry
Sounds like NFC. That will give you at least 100 kb/s
Wim
que? NFC?!
NFC (Near Field Communication) is a reuse of the protocols for contactless
smartcards. It is ment for distances of some 10 cm at reasonable datarates.
It uses load modulation or AM on a 13.56 MHz carrier (licence free ISM band)

Wim.
Terry Given
2006-11-16 09:47:03 UTC
Permalink
Post by Wim Ton
Post by Terry Given
Post by Wim Ton
Post by Terry Given
can you use a bidirectional solenoid as the transmitter, and do the
"audio" at 5Hz?
Cheers
Terry
Sounds like NFC. That will give you at least 100 kb/s
Wim
que? NFC?!
NFC (Near Field Communication) is a reuse of the protocols for contactless
smartcards. It is ment for distances of some 10 cm at reasonable datarates.
It uses load modulation or AM on a 13.56 MHz carrier (licence free ISM band)
Wim.
Danke.

Cheers
Terry

Nico Coesel
2006-10-26 20:38:35 UTC
Permalink
Post by Joerg
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 ***@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Joerg
2006-10-26 21:05:18 UTC
Permalink
Hello Nico,
Post by Nico Coesel
Post by Joerg
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
Tauno Voipio
2006-10-26 21:32:13 UTC
Permalink
Post by Joerg
Hello Nico,
Post by Nico Coesel
Post by Joerg
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
Joerg
2006-10-26 21:44:15 UTC
Permalink
Hello Tauno,
Post by Tauno Voipio
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
Paul Keinanen
2006-10-27 06:08:57 UTC
Permalink
On Thu, 26 Oct 2006 21:44:15 GMT, Joerg
Post by Joerg
Hello Tauno,
Post by Tauno Voipio
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
2006-10-27 08:06:07 UTC
Permalink
Hello Paul,
Post by Paul Keinanen
Post by Joerg
Post by Tauno Voipio
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
Didi
2006-10-26 21:48:16 UTC
Permalink
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
------------------------------------------------------
Hello Nico,
Post by Nico Coesel
Post by Joerg
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
2006-10-26 22:02:31 UTC
Permalink
Hello Didi,
Post by 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.
Post by Didi
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
Didi
2006-10-26 22:43:19 UTC
Permalink
Hi Joerg,
Post by 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).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Alex Gibson
2006-10-29 08:25:17 UTC
Permalink
Post by Didi
Hi Joerg,
Post by 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).
Could always use an ipod screen.
Make a "music video" that has the correct modulation.

Alex
Joerg
2006-10-29 17:20:28 UTC
Permalink
Hello Alex,
Post by Alex Gibson
Post by Didi
Post by 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).
Could always use an ipod screen.
Make a "music video" that has the correct modulation.
I guess the fact that I don't have an iPod (and never had the desire to
own one...) shows my age ;-)
--
Regards, Joerg

http://www.analogconsultants.com
Jim Thompson
2006-10-29 21:08:31 UTC
Permalink
On Sun, 29 Oct 2006 17:20:28 GMT, Joerg
Post by Joerg
Hello Alex,
Post by Alex Gibson
Post by Didi
Post by 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).
Could always use an ipod screen.
Make a "music video" that has the correct modulation.
I guess the fact that I don't have an iPod (and never had the desire to
own one...) shows my age ;-)
I use it for "books on tape" when I travel... the only time I have to
"read" ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.
Alex Gibson
2006-10-29 21:58:34 UTC
Permalink
Post by Joerg
Hello Alex,
Post by Alex Gibson
Post by Didi
Post by 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).
Could always use an ipod screen.
Make a "music video" that has the correct modulation.
I guess the fact that I don't have an iPod (and never had the desire to
own one...) shows my age ;-)
Maybe , maybe not :-)
Even my mother in her sixties has one (ipod shuffle).

They are great for going over lectures , or listening to language "tapes".
Plus pod casts of your favourite radio show or similar.

Nothing better than sitting back outside on the ferry every morning on the
way to work
with a good cappuccino and watching the harbour(Sydney) glide past while
listening to good music.

Alex
Joerg
2006-10-29 23:15:49 UTC
Permalink
Hello Alex,
Post by Alex Gibson
Post by Joerg
Post by Alex Gibson
Post by Didi
Post by 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).
Could always use an ipod screen.
Make a "music video" that has the correct modulation.
I guess the fact that I don't have an iPod (and never had the desire to
own one...) shows my age ;-)
Maybe , maybe not :-)
Even my mother in her sixties has one (ipod shuffle).
Even our president (US) has one, IIRC one of his daughters gave it to
him. Don't know about his father though.
Post by Alex Gibson
They are great for going over lectures , or listening to language "tapes".
Plus pod casts of your favourite radio show or similar.
Nothing better than sitting back outside on the ferry every morning on the
way to work
with a good cappuccino and watching the harbour(Sydney) glide past while
listening to good music.
My way to work is a hallway, takes about five seconds :-)

Except when going to clients but then I have a nice radio and CD player
in the car. At airports all the din is too loud anyway.
--
Regards, Joerg

http://www.analogconsultants.com
Didi
2006-10-26 22:46:37 UTC
Permalink
Hi Joerg,
Post by 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).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Joerg
2006-10-26 22:57:49 UTC
Permalink
Hello Dimiter,
Post by Didi
Post by 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).
I did that in the early 90's but not with Windows. It was DOS and fairly
easy, could still be done with an executable. It would automatically pop
up a DOS box. The only disadvantage to the user would be that they'd
have to click that little "x" up there or type in exit.

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.

It was a direct write to video card memory. Probably not a cool thing to
do these days.
Post by Didi
Post by Joerg
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,
You could actually have them use their cell phones (maybe). Call
1-800-UPDATEME or something like that.
--
Regards, Joerg

http://www.analogconsultants.com
Didi
2006-10-26 23:22:50 UTC
Permalink
Hi Joerg,
Post by Joerg
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.
Post by Joerg
It was a direct write to video card memory. Probably not a cool thing to
do these days.
Don't know about windows, can just assume they are doing it similarly
as I do it in DPS. Writing directly to video memory will not work
because the offscreen buffers are refreshed into it upon OS' decision.
However, you can write to the off-screen buffer memory (and signal
the modification), this will take you as far as the refresh rate goes
(30 Hz right now in front of me :-). Wait a minute, you can also
open a window without an offscreen buffer in DPS, it only must remain
uncovered by others to allow you to write to it the old way... I would
expect there is something equivalent in windows, too.

Dimiter

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

http://www.tgi-sci.com
------------------------------------------------------
Post by Joerg
Hello Dimiter,
Post by Didi
Post by 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).
I did that in the early 90's but not with Windows. It was DOS and fairly
easy, could still be done with an executable. It would automatically pop
up a DOS box. The only disadvantage to the user would be that they'd
have to click that little "x" up there or type in exit.
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.
It was a direct write to video card memory. Probably not a cool thing to
do these days.
Post by Didi
Post by Joerg
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,
You could actually have them use their cell phones (maybe). Call
1-800-UPDATEME or something like that.
--
Regards, Joerg
http://www.analogconsultants.com
Joerg
2006-10-27 08:09:02 UTC
Permalink
Hello Dimiter,
Post by Didi
Post by Joerg
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
Nico Coesel
2006-10-28 10:09:02 UTC
Permalink
Post by Joerg
Hello Dimiter,
Post by Didi
Post by Joerg
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.
Post by Joerg
Post by Didi
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 ***@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Joerg
2006-10-28 16:06:22 UTC
Permalink
Hello Nico,
Post by Nico Coesel
Post by Joerg
Post by Didi
Post by Joerg
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.
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.
Post by Nico Coesel
Post by Joerg
Post by Didi
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.
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.
--
Regards, Joerg

http://www.analogconsultants.com
Terry Given
2006-10-30 03:26:04 UTC
Permalink
Post by Joerg
Hello Nico,
Post by Nico Coesel
Post by Joerg
Post by Didi
Post by Joerg
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.
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.
"bizarre pathologies" - thats a lovely turn of phrase Joerg! They also
tend to occur more during power-up and power-down, so thats proobably
asking for trouble.
Post by Joerg
Post by Nico Coesel
Post by Joerg
Post by Didi
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.
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.
Can you make a crude accelerometer out of a piezo speaker, and do the
audio sans hole?

Cheers
Terry
Joerg
2006-10-30 22:23:12 UTC
Permalink
Hello Terry,
Post by Terry Given
Post by Joerg
Hello Nico,
Post by Nico Coesel
Post by Joerg
Post by Didi
Post by Joerg
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.
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.
"bizarre pathologies" - thats a lovely turn of phrase Joerg! They also
tend to occur more during power-up and power-down, so thats proobably
asking for trouble.
Post by Joerg
Post by Nico Coesel
Post by Joerg
Post by Didi
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.
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.
Can you make a crude accelerometer out of a piezo speaker, and do the
audio sans hole?
Yes. However, when winds and other noises come up the SNR quickly goes
to pots.
--
Regards, Joerg

http://www.analogconsultants.com
Le Chaud Lapin
2006-10-26 23:25:49 UTC
Permalink
Post by Joerg
Hello Dimiter,
Post by Didi
The main disadvantage I see is the necessity to write some modulation
software for Windows (yuck).
I did that in the early 90's but not with Windows. It was DOS and fairly
easy, could still be done with an executable. It would automatically pop
up a DOS box. The only disadvantage to the user would be that they'd
have to click that little "x" up there or type in exit.
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.
It was a direct write to video card memory. Probably not a cool thing to
do these days.
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.

Best,

-Le Chaud Lapin-
r***@yahoo.com
2006-10-27 04:09:38 UTC
Permalink
Post by Le Chaud Lapin
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.
Joerg
2006-10-27 08:13:51 UTC
Permalink
Post by r***@yahoo.com
Post by Le Chaud Lapin
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
r***@yahoo.com
2006-10-28 00:26:02 UTC
Permalink
Post by Joerg
Post by r***@yahoo.com
Post by Le Chaud Lapin
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?
Paul Keinanen
2006-10-28 04:44:17 UTC
Permalink
Post by r***@yahoo.com
Post by Joerg
Post by r***@yahoo.com
Post by Le Chaud Lapin
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).
Post by r***@yahoo.com
Post by Joerg
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 :-).
Post by r***@yahoo.com
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.
Post by r***@yahoo.com
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.
Post by r***@yahoo.com
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
r***@yahoo.com
2006-10-28 05:08:46 UTC
Permalink
Post by Paul Keinanen
Post by r***@yahoo.com
Post by Joerg
Post by r***@yahoo.com
Post by Le Chaud Lapin
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).
Post by r***@yahoo.com
Post by Joerg
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.
Post by Paul Keinanen
Post by r***@yahoo.com
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.
Post by Paul Keinanen
Post by r***@yahoo.com
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.
Post by Paul Keinanen
Post by r***@yahoo.com
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.
Paul Keinanen
2006-10-28 10:06:33 UTC
Permalink
Post by r***@yahoo.com
Post by Paul Keinanen
Post by r***@yahoo.com
Post by Joerg
Post by r***@yahoo.com
Post by Le Chaud Lapin
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.
Post by r***@yahoo.com
Post by Paul Keinanen
Post by r***@yahoo.com
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.
Post by r***@yahoo.com
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".
Post by r***@yahoo.com
Many people are also unclear
that you can actually have Win32 command line applications.
That is their problem.


Paul
Joerg
2006-10-28 16:19:32 UTC
Permalink
Hello Robert,


[ ... ]
Post by r***@yahoo.com
Post by Paul Keinanen
Post by r***@yahoo.com
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.
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?
--
Regards, Joerg

http://www.analogconsultants.com
r***@yahoo.com
2006-10-30 21:06:40 UTC
Permalink
Post by Joerg
Hello Robert,
[ ... ]
Post by r***@yahoo.com
Post by Paul Keinanen
Post by r***@yahoo.com
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.
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?
OK, but how many people in a given shop are likely to use it? And for
the next few years is running a second PC, 32 bit Windows (there will
be a 32 bit version of Vista), or one of the VMs a really unacceptable
solution?

I certainly sympathize, I have some DOS and Win16 stuff I have to
support too.

But, this is not unlike the complaint about the lack of legacy ports on
new PCs and laptops. The fraction of users this will impact is very,
very small. And in both cases, there are workarounds available.
Joerg
2006-10-30 22:28:49 UTC
Permalink
Hello Robert,
Post by r***@yahoo.com
Post by Joerg
Hello Robert,
[ ... ]
Post by r***@yahoo.com
Post by Paul Keinanen
Post by r***@yahoo.com
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.
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?
OK, but how many people in a given shop are likely to use it? And for
the next few years is running a second PC, 32 bit Windows (there will
be a 32 bit version of Vista), or one of the VMs a really unacceptable
solution?
If a VM is able to run legacy DOS, fine. Otherwise no, since I am not
inclined to schlepp around two laptops ;-)
Post by r***@yahoo.com
I certainly sympathize, I have some DOS and Win16 stuff I have to
support too.
But, this is not unlike the complaint about the lack of legacy ports on
new PCs and laptops. The fraction of users this will impact is very,
very small. And in both cases, there are workarounds available.
Nearly all (in my case all) programmer pods and the like have become
available as USB versions. But in the world of specialized design
software that isn't happening for works that originated at universities
and other research facilities. For much of that there is nobody around
anymore that would be able to change it. Often there isn't even anyone
who would know where the source code files are.
--
Regards, Joerg

http://www.analogconsultants.com
Didi
2006-10-26 23:08:17 UTC
Permalink
Hi Joerg,
Post by 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 only disadvantage I see is the necessity to write some modulation
software for Windows (yuck).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Didi
2006-10-26 23:18:40 UTC
Permalink
Hi Joerg,
Post by 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).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Didi
2006-10-26 23:32:57 UTC
Permalink
Hi Joerg,
Post by 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 only disadvantage I see is the necessity to write some modulation
software for Windows (yuck).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Didi
2006-10-26 23:36:27 UTC
Permalink
Hi Joerg,
Post by 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 only disadvantage I see is the necessity to write some modulation
software for Windows (yuck).
Post by Joerg
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
------------------------------------------------------
Post by Joerg
Hello Didi,
Post by 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.
Post by Didi
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
Didi
2006-10-26 23:46:48 UTC
Permalink
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....

Aplologies to all,

Dimiter
Joerg
2006-10-27 08:17:17 UTC
Permalink
Hello Dimiter,
Post by Didi
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
jasen
2006-10-29 10:02:01 UTC
Permalink
Post by Joerg
Hello Nico,
Post by Nico Coesel
Post by Joerg
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.
audio needs a microphone built into the device and a demodulator,
no cabling.

Bye.
Jasen
Joerg
2006-10-29 17:22:58 UTC
Permalink
Hello Jasen,
Post by jasen
Post by Joerg
Post by Nico Coesel
Post by Joerg
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.
audio needs a microphone built into the device and a demodulator,
no cabling.
Yes, that's the other option we had discussed here in the thread.
However, that would usually require a hole in the device for the
microphone. Not really a good option for outdoor stuff. Maybe thinning
the enclosure over the mike would be enough though.
--
Regards, Joerg

http://www.analogconsultants.com
Nico Coesel
2006-10-26 20:30:18 UTC
Permalink
Post by Joerg
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.
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 ***@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Joerg
2006-10-26 20:48:25 UTC
Permalink
Hello Nico,
Post by Nico Coesel
Post by Joerg
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.
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.
Post by Nico Coesel
... 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
jasen
2006-10-29 10:18:17 UTC
Permalink
Post by Joerg
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.
Post by Joerg
Post by Nico Coesel
... 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 ;-)
--
Bye.
Jasen
Joerg
2006-10-29 17:26:23 UTC
Permalink
Hello Jasen,
Post by jasen
Post by Joerg
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.
Would be really nice but I guess it falls in the "too good to be true"
or "there is no free lunch" category. Arlet had hinted that messing with
the protocol may be frowned upon by the FCC and that the manufacturers
don't let others in on the firmware :-(
--
Regards, Joerg

http://www.analogconsultants.com
Le Chaud Lapin
2006-10-26 21:52:06 UTC
Permalink
Post by Joerg
Hello Folks,
Hi Joerg.
Post by 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-
Joerg
2006-10-26 22:32:08 UTC
Permalink
Post by Le Chaud Lapin
Post by Joerg
Hello Folks,
Hi Joerg.
Post by 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.
Post by Le Chaud Lapin
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).
Post by Le Chaud Lapin
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
Le Chaud Lapin
2006-10-27 03:56:42 UTC
Permalink
Post by Joerg
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.

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

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.

Best,

-Le Chaud Lapin-
Joerg
2006-10-27 08:27:03 UTC
Permalink
Post by Le Chaud Lapin
Post by Joerg
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.
Post by Le Chaud Lapin
There seems like there should be something in between, super simple as
you say.
Yes!
Post by Le Chaud Lapin
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
Arlet
2006-10-27 08:52:57 UTC
Permalink
Post by Joerg
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.
Joerg
2006-10-27 09:21:08 UTC
Permalink
Hello Arlet,
Post by Arlet
Post by Joerg
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.
Post by Arlet
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
David R Brooks
2006-10-27 22:25:54 UTC
Permalink
Post by Joerg
Post by Le Chaud Lapin
Post by Joerg
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.
Post by Le Chaud Lapin
There seems like there should be something in between, super simple as
you say.
Yes!
Post by Le Chaud Lapin
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?
Joerg
2006-10-27 22:48:54 UTC
Permalink
Hello David,
Post by David R Brooks
Post by Joerg
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
James Waldby
2006-10-27 07:08:38 UTC
Permalink
Joerg wrote:
[...]
Post by Joerg
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
[...]
Post by Joerg
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
Joerg
2006-10-27 08:30:21 UTC
Permalink
Hello James,
Post by James Waldby
Post by Joerg
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
[...]
Post by Joerg
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
jasen
2006-10-29 10:21:26 UTC
Permalink
Post by Joerg
Hello James,
Post by James Waldby
Post by Joerg
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
[...]
Post by Joerg
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 ...
--
Bye.
Jasen
Joerg
2006-10-29 17:28:32 UTC
Permalink
Hello Jasen,
Post by jasen
Post by Joerg
Post by James Waldby
Post by Joerg
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
[...]
Post by Joerg
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 ...
The laptops I had seen with LCD for machine status messaging usually
didn't have that little screen backlit.
--
Regards, Joerg

http://www.analogconsultants.com
vasile
2006-10-28 05:45:32 UTC
Permalink
Post by Joerg
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)
Post by 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.
Again, only IF the executable will be received clean and the CRC will
be OK.
Much doubt will be like this on long distance.
Post by Joerg
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.
Post by Joerg
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 :)
Post by Joerg
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
2006-10-28 10:06:34 UTC
Permalink
Post by vasile
Post by Joerg
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
2006-10-28 16:30:10 UTC
Permalink
Hello Paul,
Post by Paul Keinanen
Post by vasile
Post by Joerg
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.
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.
Post by Paul Keinanen
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.
--
Regards, Joerg

http://www.analogconsultants.com
Joerg
2006-10-28 16:26:22 UTC
Permalink
Hello Vasile,
Post by vasile
Post by Joerg
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)
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.
Post by vasile
Post by 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.
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.
Post by vasile
Post by Joerg
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.
That's why we only design the good stuff :-)
Post by vasile
Post by Joerg
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 :)
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 :-)
Post by vasile
Post by Joerg
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 ?
Because you will neither need any cables nor any accessory to the
laptop. Wifi is mostly already built in.
--
Regards, Joerg

http://www.analogconsultants.com
Alex Gibson
2006-10-29 22:04:43 UTC
Permalink
Post by Joerg
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.
micro sd or mmc card to expensive ?

What about wireless usb ?
Probably currently to expensive and nothing available (easily)
but will get cheaper and more available.
Supposedly in some of the current pc chipsets but not enabled.


Alex
Joerg
2006-10-29 23:11:32 UTC
Permalink
Hello Alex,
Post by Alex Gibson
Post by Joerg
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.
micro sd or mmc card to expensive ?
Yes, way too expensive here. Plus too much chance for contact failure,
ESD, contamination, water intrusion etc.
Post by Alex Gibson
What about wireless usb ?
Probably currently to expensive and nothing available (easily)
but will get cheaper and more available.
Supposedly in some of the current pc chipsets but not enabled.
Anything that sticks out from a laptop will eventually break in the
field. Unsually in the least convenient place (several miles up a dirt
road in pouring rain...). Or the USB stick fell out of the tool box but
who knows where.
--
Regards, Joerg

http://www.analogconsultants.com
Alex Gibson
2006-10-30 21:53:17 UTC
Permalink
Post by Joerg
Hello Alex,
Post by Alex Gibson
What about wireless usb ?
Probably currently to expensive and nothing available (easily)
but will get cheaper and more available.
Supposedly in some of the current pc chipsets but not enabled.
Anything that sticks out from a laptop will eventually break in the field.
Unsually in the least convenient place (several miles up a dirt road in
pouring rain...). Or the USB stick fell out of the tool box but who knows
where.
No not an adaptor for wireless but wireless usb (uwb)
supposed to be already in some of Intels new chipsets.
Supports up to 480Mbps up to a few metres away.


Alex
Joerg
2006-10-30 22:33:04 UTC
Permalink
Hello Alex,
Post by Alex Gibson
Post by Joerg
Post by Alex Gibson
What about wireless usb ?
Probably currently to expensive and nothing available (easily)
but will get cheaper and more available.
Supposedly in some of the current pc chipsets but not enabled.
Anything that sticks out from a laptop will eventually break in the field.
Unsually in the least convenient place (several miles up a dirt road in
pouring rain...). Or the USB stick fell out of the tool box but who knows
where.
No not an adaptor for wireless but wireless usb (uwb)
supposed to be already in some of Intels new chipsets.
Supports up to 480Mbps up to a few metres away.
But I am afraid it will be some time until laptops have that built in.
Also, most agencies or businesses won't allow their staff to order new
ones as long as the "old" ones haven't reached the end of the
depreciation tables. Something like three years, usually.

Also, I'd need more than a few meters. More like 30 or so, and it has to
go from inside a vehicle to a pole. In rain, sleet, hail, loads of
thawed and re-frozen snow, the works.
--
Regards, Joerg

http://www.analogconsultants.com
Continue reading on narkive:
Loading...