Forums

WLAN card to generate pulsed RF?

Started by Joerg October 26, 2006
Hello Nico,

> >>The only other option I could think of (and I have done that before) is >>to provide a photodiode and let the LCD screen flash. However, that is >>really slow and can annoy others who have to work close to that laptop. > > > Why not use the audio output of the laptop? Every laptop has one and > it is very easy to program. If you get really nifty, you can > distribute your firmware as an mp3 file. > > Still, I think USB really is the sensible way to go for these sort of > things. USB to serial adapter chips are commonly available and small > (like the CP2101). Cabling is not an issue if you use standard > (miniature) USB sockets. Drivers can be made available from your > website. >
Either one needs cables. People forget to take them along, they can be damaged, connectors become dirty, it could be raining or snowing etc. The audio port on laptops is a 3.5mm audio jack. Those are IMHO rather unreliable. USB is bulky and expensive. Think about the $2-3 class in production cost. A mini-jack is already quite cost prohibitive there but the electrical USB funtionality would really blow that out of the water. On installed sensors the poor users would stand there in the pouring rain, shielding their precious PDAs, trying to push the cable into some tiny jack, trying to hold the flashlight with the third hand which they don't have... -- Regards, Joerg http://www.analogconsultants.com
Joerg wrote:
> Hello Nico, > >> >>> The only other option I could think of (and I have done that before) >>> is to provide a photodiode and let the LCD screen flash. However, >>> that is really slow and can annoy others who have to work close to >>> that laptop. >> >> >> >> Why not use the audio output of the laptop? Every laptop has one and >> it is very easy to program. If you get really nifty, you can >> distribute your firmware as an mp3 file. >> >> Still, I think USB really is the sensible way to go for these sort of >> things. USB to serial adapter chips are commonly available and small >> (like the CP2101). Cabling is not an issue if you use standard >> (miniature) USB sockets. Drivers can be made available from your >> website. >> > > Either one needs cables. People forget to take them along, they can be > damaged, connectors become dirty, it could be raining or snowing etc. > The audio port on laptops is a 3.5mm audio jack. Those are IMHO rather > unreliable. USB is bulky and expensive. > > Think about the $2-3 class in production cost. A mini-jack is already > quite cost prohibitive there but the electrical USB funtionality would > really blow that out of the water. On installed sensors the poor users > would stand there in the pouring rain, shielding their precious PDAs, > trying to push the cable into some tiny jack, trying to hold the > flashlight with the third hand which they don't have...
Please note that it's fairly easy to detect the presence of a signal in on-off keying. It is much more difficult to reliably detect the absence (off state) of the signal. This is one of the main reasons that radio teletype communication (RTTY) is using frequency-shift keying instead of on-off keying. The traditional radio keying method is on-off (since G. Marconi). -- Tauno Voipio, OH2UG tauno voipio (at) iki fi
Hello Tauno,

> > Please note that it's fairly easy to detect the presence > of a signal in on-off keying. It is much more difficult to > reliably detect the absence (off state) of the signal. > > This is one of the main reasons that radio teletype communication > (RTTY) is using frequency-shift keying instead of on-off keying. > The traditional radio keying method is on-off (since G. Marconi). >
I am aware of that. However, in this case we would not have to deal with much noise. The main concern is simplicity of the receiver circuitry. It is quite easy to build an AM detector while FM becomes involved. When I was more active in ham radio I was astonished what automated code readers could do even though that was just beginning in the 70's (back when you had to plunk down >$2 for a simple 7474). Most of us could read morse code where the signal was a wee change in a garbled soup of static. In fact, some scientists claimed that hams could beat Shannon's theorem. Don't know about that but those folks who didn't yet master code at sufficient speeds built themselves automatic readers and these would work down to rather flimsy signal levels. Amazing. -- Regards, Joerg http://www.analogconsultants.com
Joerg wrote:

> It surprises me though that it wouldn't be legal at least around > 2.450GHz. That's where microwave ovens blast off hundreds of watts, some > of which leak out. They don't adhere to any modulation scheme, it's more > or less filtered DC plus 60/120Hz drooping picket fences to each side (a > whole lot wider for the ones with switcher supplies). On the spectrum > analyzer these can swamp whatever WLAN is in the room.
In the US, the FCC (Part18) allows microwave ovens to use the 2.4 GHz ISM band, but only because they aren't communication devices. If you want to use the same frequency for communication, you fall under Part 15 of the FCC rules which control your modulation, spectral mask, output power, etc. Other countries have different regulations which may be more or less strict.
Hi Joerg,

> Either one needs cables. ....
What about a mike? I am not sure they get as cheap as photodiodes, but some tiny speakers probably will be cheap enough. Then, you can just use Kansas City modulation [for those who do not have a memory what this was: 4 periods of 1200 Hz=0, 8 periods of 2400 Hz=1], modulate an S3 (or even its 24-bit or 23-bit address variations, I have implemented them both but many years ago and now don't remember their respective S-numbers....). That would take minimal resources, I have managed to do Kansas City using a 1 MHz 6809 and part of a 6840 timer 20 or so years ago. Error correction will be limited to checksum only with S-records, though, which may be an issue, you may have to use some tougher error checking depending on how dramatic a device failure after reflashing would be... Then again, I remember my above mentioned "modem" would not be confused by a phone line signal - voice or whatever - and would detect all interleaved data frames, very rarely rejecting some because of checksum error(s). The other suggested option - flashing a display window - may also be good enough, and bringing that down to a binary stream may be somewhat cheaper than with the mike (the latter would likely need an opamp and a comparator/schmitt trigger, whereas the photodiode might take no opamp). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Joerg wrote:
> Hello Nico, > > > > >>The only other option I could think of (and I have done that before) is > >>to provide a photodiode and let the LCD screen flash. However, that is > >>really slow and can annoy others who have to work close to that laptop. > > > > > > Why not use the audio output of the laptop? Every laptop has one and > > it is very easy to program. If you get really nifty, you can > > distribute your firmware as an mp3 file. > > > > Still, I think USB really is the sensible way to go for these sort of > > things. USB to serial adapter chips are commonly available and small > > (like the CP2101). Cabling is not an issue if you use standard > > (miniature) USB sockets. Drivers can be made available from your > > website. > > > > Either one needs cables. People forget to take them along, they can be > damaged, connectors become dirty, it could be raining or snowing etc. > The audio port on laptops is a 3.5mm audio jack. Those are IMHO rather > unreliable. USB is bulky and expensive. > > Think about the $2-3 class in production cost. A mini-jack is already > quite cost prohibitive there but the electrical USB funtionality would > really blow that out of the water. On installed sensors the poor users > would stand there in the pouring rain, shielding their precious PDAs, > trying to push the cable into some tiny jack, trying to hold the > flashlight with the third hand which they don't have... > > -- > Regards, Joerg > > http://www.analogconsultants.com
Joerg wrote:
> Hello Folks,
Hi Joerg.
> b. The user receives one executable file containing the new firmware, > code to initialize the WLAN port and code to run that port in a simple > (but legal) AM on/off mode. This executable would now be started. > > Any idea on how to get point "b." done? Tried Google but pulled numerous > blanks. Then again, I am not a software guy so maybe I am looking in the > wrong places.
Not possible. Modulation is not under software control, and the firmware is not accessible, at least not in traditional sense. I didn't look to see what chipsets are most popular for the software portion of the adapter, but I'd be suprised if, on typical chip, you could control modulation at that level. And if you could, the software would have to be in firmware, so you'd have to write a program to... 1). Extract firmware from chip 2). Reprogram chipd to do your business 3). Put firmware back. This process would have to happen in context of a device driver, which is...ahum...non-trivial, at least on Windows. Since you only want 2400 baud, why not do the same with UART? Most PC's still come with 1 UART, and the microcontrollers have them. I would make the communication bi-directional, as you would never know if device received the file intact from PC. Use BPSK or BFSK modulator/demodulator pair at UART on device and on PC, powered by UART itself on PC side (could be made very small, about size of US quarter). The mark/space scheme you refer to is natural to the UART. Use AND gate type collision detection circuit to indicate collision. Let DTR activate transmitter, DSR be connected to RSSI circuit to say when foreign entitity has activated its transmitter. Set UART mode to 2400,8,n,1 for testing, and crank it up gradually toward 115,200, while keeping BER within certain accecptable range. Mititgate errors that get through with software FEC, or, just caculate CRC-32 on data and have either device retransmit entire frame if there is a problem. You will know if there is a problem when, after sending a frame from the source, you do not receive an acknowledge from the target. You can add cryptography on top of this relatively easily if that is a concern. Actually, this is not a bad idea for a product. Your motivational points about Bluetooth and infrared are valid - Bluetooth is too complicated in fact. They did too much and not enough, simultaneously, if that makes sense. The only limitation is speed, but at 115,200 bps, that's 10KB/s of useful information, not horrifically bad. -Le Chaud Lapin-
Hello Arlet,

> >>It surprises me though that it wouldn't be legal at least around >>2.450GHz. That's where microwave ovens blast off hundreds of watts, some >>of which leak out. They don't adhere to any modulation scheme, it's more >>or less filtered DC plus 60/120Hz drooping picket fences to each side (a >>whole lot wider for the ones with switcher supplies). On the spectrum >>analyzer these can swamp whatever WLAN is in the room. > > > In the US, the FCC (Part18) allows microwave ovens to use the 2.4 GHz > ISM band, but only because they aren't communication devices. If you > want to use the same frequency for communication, you fall under Part > 15 of the FCC rules which control your modulation, spectral mask, > output power, etc. >
Well, technically my scheme would not be "communication" because there is never a feedback. Could possibly be called, ahem, flash memory cell therapy. But I guess this would be stretching the rules a bit far ;-)
> Other countries have different regulations which may be more or less > strict. >
It is even stricter in other countries, especially those with communications monopolies. They don't like it when anyone encroaches onto their turf. Some even don't allow you to run an optical over-the-air or any other link between your house and the direct neighbors because they "own" the right of way for anything that involves the exchange of information. They do let you have a chat across the fence though. -- Regards, Joerg http://www.analogconsultants.com
Hello Didi,

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

> Joerg wrote: > >>Hello Folks, > > Hi Joerg. > >>b. The user receives one executable file containing the new firmware, >>code to initialize the WLAN port and code to run that port in a simple >>(but legal) AM on/off mode. This executable would now be started. >> >>Any idea on how to get point "b." done? Tried Google but pulled numerous >>blanks. Then again, I am not a software guy so maybe I am looking in the >>wrong places. > > > Not possible. Modulation is not under software control, and the > firmware is not accessible, at least not in traditional sense. I > didn't look to see what chipsets are most popular for the software > portion of the adapter, but I'd be suprised if, on typical chip, you > could control modulation at that level. And if you could, the software > would have to be in firmware, so you'd have to write a program to... > > 1). Extract firmware from chip > 2). Reprogram chipd to do your business > 3). Put firmware back. > > This process would have to happen in context of a device driver, which > is...ahum...non-trivial, at least on Windows. >
That's how it appears to be after Arlet's comments. He mentioned that messing with this could be akin to messing with you car's engine controller, meaning it could compromise its legality in terms of emissions etc. Also, it would almost have to be a special device driver that could be licensed from somewhere when it all goes into production.
> Since you only want 2400 baud, why not do the same with UART? Most > PC's still come with 1 UART, and the microcontrollers have them. > > I would make the communication bi-directional, as you would never know > if device received the file intact from PC. > > Use BPSK or BFSK modulator/demodulator pair at UART on device and on > PC, powered by UART itself on PC side (could be made very small, about > size of US quarter). The mark/space scheme you refer to is natural to > the UART. Use AND gate type collision detection circuit to indicate > collision. Let DTR activate transmitter, DSR be connected to RSSI > circuit to say when foreign entitity has activated its transmitter. > Set UART mode to 2400,8,n,1 for testing, and crank it up gradually > toward 115,200, while keeping BER within certain accecptable range. > Mititgate errors that get through with software FEC, or, just caculate > CRC-32 on data and have either device retransmit entire frame if there > is a problem. You will know if there is a problem when, after sending > a frame from the source, you do not receive an acknowledge from the > target. >
Unfortunately that would require a cable which is what I want to avoid. Also, newer laptops do not have a RS232 port anymore. You would need either a docking station (impossible in the field) or a separate USB-RS232 converter pod (adding even more cabling stuff).
> You can add cryptography on top of this relatively easily if that is a > concern. > > Actually, this is not a bad idea for a product. Your motivational > points about Bluetooth and infrared are valid - Bluetooth is too > complicated in fact. They did too much and not enough, simultaneously, > if that makes sense. The only limitation is speed, but at 115,200 > bps, that's 10KB/s of useful information, not horrifically bad. >
Bluetooth is indeed too complicated. Speed is not an issue as it can be even slower than 2400bd. Much slower if needed. But simplicity is paramount here, both with respect to hardware as well as code space for the bootloader on the uC. Irda would have been nice but this seems to not really have caught on. None of the laptops I have checked had it. And even there it would remain to be seen how much mandatory overhead they have crammed into it which would get in the way of simplicity. Irda may be water under the bridge though. If too many laptops in the field don't have it then I cannot use it. -- Regards, Joerg http://www.analogconsultants.com
Hi Joerg,

> The advantage is that it doesn't need a hole, just a translucent section > in the enclosure.
I agree, this is a significant advantage. Probably the way to go if you have to be waterproof - you will still be able to make 10 bpS easily, which at your 1 - 2 K is still adequate (vs. the 300 bpS of Kansas City). The main disadvantage I see is the necessity to write some modulation software for Windows (yuck).
> The 1200/2400 scheme might be simple enough but to cram that into 0.5k > or less of bootloader space could be tough.
Oh I am sure it can be done (it has been done by me and other people some 20 years ago, it should still be doable :-). That being said, the previously quoted argumentation holds still valid, no hole for the mike with a photodiode. On the other hand, you can use anything to record the Kansas City stream in an MP3 file and distribute this without having to mess around with MS hoops etc. You can even use a $50 MP3 player, put ist earplug near the mike, and not need to carry a laptop, once you get rid of the hole in the case issue. That would solve also the problem about annoying other people, not the waterproof requirement, though. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Joerg wrote:
> Hello Didi, > > > > >>Either one needs cables. .... > > > > What about a mike? I am not sure they get as cheap as photodiodes, > > but some tiny speakers probably will be cheap enough. Then, you can > > just use Kansas City modulation [for those who do not have a memory > > what this was: 4 periods of 1200 Hz=0, 8 periods of 2400 Hz=1], > > modulate > > an S3 (or even its 24-bit or 23-bit address variations, I have > > implemented > > them both but many years ago and now don't remember their respective > > S-numbers....). That would take minimal resources, I have managed to > > do Kansas City using a 1 MHz 6809 and part of a 6840 timer 20 or > > so years ago. Error correction will be limited to checksum only with > > S-records, though, which may be an issue, you may have to use some > > tougher error checking depending on how dramatic a device failure after > > reflashing would be... Then again, I remember my above mentioned > > "modem" would not be confused by a phone line signal - voice or > > whatever - and would detect all interleaved data frames, very rarely > > rejecting some because of checksum error(s). > > > Audio can annoy others. Many times you have to update firmware in the > field without moving the device, by bringing the laptop or PDA there. > The 1200/2400 scheme might be simple enough but to cram that into 0.5k > or less of bootloader space could be tough. > > While the cost of a mike would be negligible thanks to cell phones and > all that it requires a hole in the target device. That would be a > serious concern for anything that needs to operate outdoors. > > > > The other suggested option - flashing a display window - may also be > > good enough, and bringing that down to a binary stream may be somewhat > > cheaper than with the mike (the latter would likely need an opamp > > and a comparator/schmitt trigger, whereas the photodiode might > > take no opamp). > > > > The advantage is that it doesn't need a hole, just a translucent section > in the enclosure. The photodiode can, for example, be placed where a > display is. > > -- > Regards, Joerg > > http://www.analogconsultants.com