Sign in
Search piclist
Subscribe to piclist
piclist by Keywords
12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx
Ads
Discussion Groups
See Also
Discussion Groups | Piclist | Application: Remote command reception
A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
Application: Remote command reception - John - Apr 17 1:58:00 2005
Hello everyone. This is my first time posting on this list but I
have been reading for several months now and I've learned quite a bit
from the answers you people have given. I have a question about
remote applications. I have a PIC18F2480 that will be receiving data
from an RF receiver(AFSK I believe but i'm not sure yet). The data
will actually be remote commands. Some of these commands would be:
transmit collected data, reset system etc. Also, the period that a
scientific instrument is active is also controlled by the PIC. The
PIC is interfaced to a DS1371 real time clcok which provides a 32-bit
count that gives an elapsed time MMDDYY HHMMSS. Now, one of the
commands has to be:
#Turn on the instrument at this time(32 bit number for desired
elapsed time)
I figure that the total command word would probably be 64 bits once
the sync bytes and checksums are included. I was just wondering if
anyone has any references I can use first for creating a reliable
command reception system and software to interpret commands received
through sync serial. And second, how can I make the system reliable
in an environment where comm. links might be UNreliable. I
appreciate any input anyone can give me.
-CJ
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Application: Remote command reception - rtstofer - Apr 17 23:38:00 2005
There are protocols commonly used for this type of thing such as
DLC - data link control and others. Try Google.
Basically, your message should have unique components that can't be
misinterpreted - this probably means that a multibit binary command
is not the way to go.
You can see how the ASCII character set was designed with special
control chars to control message formatting
http://www.blast.com/software/data_pump/DP_ASCII_Char.html
I wouldn't get too complicated but I might have a special char to
start a message, the message in ASCII text, a special char to end a
message and a checksum of the message itself. Each character could
be sent with parity but the checksum does the real work. In fact,
if you are really worried about the transmission, implement a Cyclic
Redundancy Check (CRC) at the end of the message instead of a
checksum.
The receiver should also reply with ACK/NAK after receiving a
packet. And the transmitter should check that it gets one or the
other and deal with the problem. You could even implement a return
packet which would be more secure that a single ACK/NAK char. --- In piclist@picl..., "John" <DiamondDyn@a...> wrote:
>
> Hello everyone. This is my first time posting on this list but I
> have been reading for several months now and I've learned quite a
bit
> from the answers you people have given. I have a question about
> remote applications. I have a PIC18F2480 that will be receiving
data
> from an RF receiver(AFSK I believe but i'm not sure yet). The
data
> will actually be remote commands. Some of these commands would
be:
> transmit collected data, reset system etc. Also, the period that
a
> scientific instrument is active is also controlled by the PIC.
The
> PIC is interfaced to a DS1371 real time clcok which provides a 32-
bit
> count that gives an elapsed time MMDDYY HHMMSS. Now, one of the
> commands has to be:
>
> #Turn on the instrument at this time(32 bit number for desired
> elapsed time)
>
> I figure that the total command word would probably be 64 bits
once
> the sync bytes and checksums are included. I was just wondering
if
> anyone has any references I can use first for creating a reliable
> command reception system and software to interpret commands
received
> through sync serial. And second, how can I make the system
reliable
> in an environment where comm. links might be UNreliable. I
> appreciate any input anyone can give me.
>
> -CJ
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: Application: Remote command reception - Mr S - Apr 18 0:54:00 2005
This description is spot-on with a protocol called
TNPP (telocator network paging protocol) used in the
paging industry. Several of the protocols used for
narrowband RF transmissions would be suitable for low
bandwidth RF transmission requirements.
Along those same lines, POCSAG is an over the air
protocol that has forward error correction built into
it, and is the basis for most, if not all, modern day
paging traffic: CRC-16, robust addressing, and
bit-interleaving for error correction make this style
of transmission almost unbeatable for narrowband
requirements.
You might want to omitt or avoid the battery saving
techniques and just use the basic protocol functions.
All that you need to ensure message reception are
built into such protocols, as they have been designed
to be used in poor signal conditions, and to operate
in the presence of interfering signals and noise.
POCSAG and TNPP support binary message transmission as
well if this is what you require, though it is based
on ASCII text transmission.
Use Google to find the details of either protocol. --- rtstofer <rstofer@rsto...> wrote: >
> There are protocols commonly used for this type of
> thing such as
> DLC - data link control and others. Try Google.
>
> Basically, your message should have unique
> components that can't be
> misinterpreted - this probably means that a multibit
> binary command
> is not the way to go.
>
> You can see how the ASCII character set was designed
> with special
> control chars to control message formatting
>
http://www.blast.com/software/data_pump/DP_ASCII_Char.html
>
> I wouldn't get too complicated but I might have a
> special char to
> start a message, the message in ASCII text, a
> special char to end a
> message and a checksum of the message itself. Each
> character could
> be sent with parity but the checksum does the real
> work. In fact,
> if you are really worried about the transmission,
> implement a Cyclic
> Redundancy Check (CRC) at the end of the message
> instead of a
> checksum.
>
> The receiver should also reply with ACK/NAK after
> receiving a
> packet. And the transmitter should check that it
> gets one or the
> other and deal with the problem. You could even
> implement a return
> packet which would be more secure that a single
> ACK/NAK char. > --- In piclist@picl..., "John"
> <DiamondDyn@a...> wrote:
> >
> > Hello everyone. This is my first time posting on
> this list but I
> > have been reading for several months now and I've
> learned quite a
> bit
> > from the answers you people have given. I have a
> question about
> > remote applications. I have a PIC18F2480 that
> will be receiving
> data
> > from an RF receiver(AFSK I believe but i'm not
> sure yet). The
> data
> > will actually be remote commands. Some of these
> commands would
> be:
> > transmit collected data, reset system etc. Also,
> the period that
> a
> > scientific instrument is active is also controlled
> by the PIC.
> The
> > PIC is interfaced to a DS1371 real time clcok
> which provides a 32-
> bit
> > count that gives an elapsed time MMDDYY HHMMSS.
> Now, one of the
> > commands has to be:
> >
> > #Turn on the instrument at this time(32 bit
> number for desired
> > elapsed time)
> >
> > I figure that the total command word would
> probably be 64 bits
> once
> > the sync bytes and checksums are included. I was
> just wondering
> if
> > anyone has any references I can use first for
> creating a reliable
> > command reception system and software to interpret
> commands
> received
> > through sync serial. And second, how can I make
> the system
> reliable
> > in an environment where comm. links might be
> UNreliable. I
> > appreciate any input anyone can give me.
> >
> > -CJ > to unsubscribe, go to http://www.yahoogroups.com and
> follow the instructions
> Yahoo! Groups Links > piclist-unsubscribe@picl...
__________________________________
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
TNPP (telocator network paging protocol) used in the
paging industry. Several of the protocols used for
narrowband RF transmissions would be suitable for low
bandwidth RF transmission requirements.
Along those same lines, POCSAG is an over the air
protocol that has forward error correction built into
it, and is the basis for most, if not all, modern day
paging traffic: CRC-16, robust addressing, and
bit-interleaving for error correction make this style
of transmission almost unbeatable for narrowband
requirements.
You might want to omitt or avoid the battery saving
techniques and just use the basic protocol functions.
All that you need to ensure message reception are
built into such protocols, as they have been designed
to be used in poor signal conditions, and to operate
in the presence of interfering signals and noise.
POCSAG and TNPP support binary message transmission as
well if this is what you require, though it is based
on ASCII text transmission.
Use Google to find the details of either protocol. --- rtstofer <rstofer@rsto...> wrote: >
> There are protocols commonly used for this type of
> thing such as
> DLC - data link control and others. Try Google.
>
> Basically, your message should have unique
> components that can't be
> misinterpreted - this probably means that a multibit
> binary command
> is not the way to go.
>
> You can see how the ASCII character set was designed
> with special
> control chars to control message formatting
>
http://www.blast.com/software/data_pump/DP_ASCII_Char.html
>
> I wouldn't get too complicated but I might have a
> special char to
> start a message, the message in ASCII text, a
> special char to end a
> message and a checksum of the message itself. Each
> character could
> be sent with parity but the checksum does the real
> work. In fact,
> if you are really worried about the transmission,
> implement a Cyclic
> Redundancy Check (CRC) at the end of the message
> instead of a
> checksum.
>
> The receiver should also reply with ACK/NAK after
> receiving a
> packet. And the transmitter should check that it
> gets one or the
> other and deal with the problem. You could even
> implement a return
> packet which would be more secure that a single
> ACK/NAK char. > --- In piclist@picl..., "John"
> <DiamondDyn@a...> wrote:
> >
> > Hello everyone. This is my first time posting on
> this list but I
> > have been reading for several months now and I've
> learned quite a
> bit
> > from the answers you people have given. I have a
> question about
> > remote applications. I have a PIC18F2480 that
> will be receiving
> data
> > from an RF receiver(AFSK I believe but i'm not
> sure yet). The
> data
> > will actually be remote commands. Some of these
> commands would
> be:
> > transmit collected data, reset system etc. Also,
> the period that
> a
> > scientific instrument is active is also controlled
> by the PIC.
> The
> > PIC is interfaced to a DS1371 real time clcok
> which provides a 32-
> bit
> > count that gives an elapsed time MMDDYY HHMMSS.
> Now, one of the
> > commands has to be:
> >
> > #Turn on the instrument at this time(32 bit
> number for desired
> > elapsed time)
> >
> > I figure that the total command word would
> probably be 64 bits
> once
> > the sync bytes and checksums are included. I was
> just wondering
> if
> > anyone has any references I can use first for
> creating a reliable
> > command reception system and software to interpret
> commands
> received
> > through sync serial. And second, how can I make
> the system
> reliable
> > in an environment where comm. links might be
> UNreliable. I
> > appreciate any input anyone can give me.
> >
> > -CJ > to unsubscribe, go to http://www.yahoogroups.com and
> follow the instructions
> Yahoo! Groups Links > piclist-unsubscribe@picl...
__________________________________
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )