error correction in a wireless app
Archiver
Posts: 46,084
Hi guys.
I have a wireless application that we have successfully working up
to about 250ft reliably, and as much as 900ft hit and miss.
We are using the Serin command with a Wait(sync) command to watch
for a specific sync. signal from the transmitter.
Is there any better way to do this and have more reliable results?
The unit is a transmitter/receiver pair, so no handshaking is
possible.
Is there a way to possibly bring any and all data in, and do better
analysis or forward error correction to interpret the data?
I know there is signal there, as we are monitoring with a spectrum
analyzer, and if I remove the wait(sync) portion it receives the
data, but its usually somewhat corrupt.
Any ideas welcome.
Thanks in advance
Jody
I have a wireless application that we have successfully working up
to about 250ft reliably, and as much as 900ft hit and miss.
We are using the Serin command with a Wait(sync) command to watch
for a specific sync. signal from the transmitter.
Is there any better way to do this and have more reliable results?
The unit is a transmitter/receiver pair, so no handshaking is
possible.
Is there a way to possibly bring any and all data in, and do better
analysis or forward error correction to interpret the data?
I know there is signal there, as we are monitoring with a spectrum
analyzer, and if I remove the wait(sync) portion it receives the
data, but its usually somewhat corrupt.
Any ideas welcome.
Thanks in advance
Jody
Comments
>Hi guys.
>
>I have a wireless application that we have successfully working up
>to about 250ft reliably, and as much as 900ft hit and miss.
>
>We are using the Serin command with a Wait(sync) command to watch
>for a specific sync. signal from the transmitter.
>
>Is there any better way to do this and have more reliable results?
>The unit is a transmitter/receiver pair, so no handshaking is
>possible.
>
>Is there a way to possibly bring any and all data in, and do better
>analysis or forward error correction to interpret the data?
>
>I know there is signal there, as we are monitoring with a spectrum
>analyzer, and if I remove the wait(sync) portion it receives the
>data, but its usually somewhat corrupt.
>
>Any ideas welcome.
>
>Thanks in advance
>Jody
You didn't mention the baud rate you're using. Lower baud rate may improve
reliability.
Also, if a bit of cost is no object, you can use a pair of Packet Terminal
Node Controllers (TNCs), one between the Stamp and the RF device and one on
the other end between the RF device and whatever. The TNCs will negotiate
an errorless transfer of data once it is handed to them by the Stamp or
device on the other end and all you need to worry about is simple serial
send receive at RS232 levels. Most TNCs will accept 0 - 5 volts as well as
true RS232. They typically run 1200 baud, but can be slowed to 300
baud. Some higher cost units run 9600 baud. You can set the Stamp-to-TNC
data rate and the TNC-TNC data rate separately, meaning you can communicate
Stamp to TNC at say 1200 baud and use 300 baud for TNC-TNC to improve
transfer rate on a marginal path. The TNCs will retry until they get thru
or time out. You can set them to NEVER time out in which case they try
forever. The TNCs will perform a full end-to-end acknowledgement that is
completely transparent to the Stamp.
Since they contain a fairly large send/receive buffer, you can set the comm
rate from Stamp to TNC at say 300 baud or 1200 baud and let TNC
communication remain at 1200 baud.
A source of such devices is Kantronics, http://www.kantronics.com/
You can also find these things used on eBay considerably cheaper than new.
Jim H
communication. A dedicated transmitter and a dedicated receiver.
The only way to solve this might be to go with a transceiver set.
I just thought there might be another way to do this with code. I
know I am receiving the data. (at 100ft I have -85db of signal
strenght) and if I remove the sync. command it gets the data. Its
usually corrupting the sync. bit, so the data isn't getting through.
thanks
Jody
--- In basicstamps@y..., Jim Higgins <HigginsJ@s...> wrote:
> At 16:16 04/30/02, moparjody wrote:
> >Hi guys.
> >
> >I have a wireless application that we have successfully working up
> >to about 250ft reliably, and as much as 900ft hit and miss.
> >
> >We are using the Serin command with a Wait(sync) command to watch
> >for a specific sync. signal from the transmitter.
> >
> >Is there any better way to do this and have more reliable results?
> >The unit is a transmitter/receiver pair, so no handshaking is
> >possible.
> >
> >Is there a way to possibly bring any and all data in, and do
better
> >analysis or forward error correction to interpret the data?
> >
> >I know there is signal there, as we are monitoring with a spectrum
> >analyzer, and if I remove the wait(sync) portion it receives the
> >data, but its usually somewhat corrupt.
> >
> >Any ideas welcome.
> >
> >Thanks in advance
> >Jody
>
> You didn't mention the baud rate you're using. Lower baud rate
may improve
> reliability.
>
> Also, if a bit of cost is no object, you can use a pair of Packet
Terminal
> Node Controllers (TNCs), one between the Stamp and the RF device
and one on
> the other end between the RF device and whatever. The TNCs will
negotiate
> an errorless transfer of data once it is handed to them by the
Stamp or
> device on the other end and all you need to worry about is simple
serial
> send receive at RS232 levels. Most TNCs will accept 0 - 5 volts
as well as
> true RS232. They typically run 1200 baud, but can be slowed to
300
> baud. Some higher cost units run 9600 baud. You can set the
Stamp-to-TNC
> data rate and the TNC-TNC data rate separately, meaning you can
communicate
> Stamp to TNC at say 1200 baud and use 300 baud for TNC-TNC to
improve
> transfer rate on a marginal path. The TNCs will retry until they
get thru
> or time out. You can set them to NEVER time out in which case
they try
> forever. The TNCs will perform a full end-to-end acknowledgement
that is
> completely transparent to the Stamp.
>
> Since they contain a fairly large send/receive buffer, you can set
the comm
> rate from Stamp to TNC at say 300 baud or 1200 baud and let TNC
> communication remain at 1200 baud.
>
> A source of such devices is Kantronics, http://www.kantronics.com/
>
> You can also find these things used on eBay considerably cheaper
than new.
>
> Jim H