• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Retransmission at different rate

Status
Not open for further replies.

joellee

New Member
Hi guys,

The task that I am required to do is to convert a 4800bps data which has a bit period of 1/56000 seconds, into 2400bps with a bit period of 1/4800s.

So essentially, you can think of it has trimming half of the data, and transmitting at a different rate - with a different utilization (or duty cycle if you can call it that).

I'm using Hi-tech C to do the programming, and a PIC18F2550.
I've been looking around for sample codes that does that, but couldn't quite find much. The extent that i have thought thus far, is basically:

Set 1 pin for input
Set 1 pin for output

Take data from input pin and store it in an array using oscillator A.
and output half the array (to half the data) to output pin using a different oscillator B.

Since i'm planning to have a duty cycle of 50%, I was thinking of using a watchdog timer and make the input pin interrupt driven.

This is my first time with PIC, and any help would be appreciated. Or if you could recommend me to some websites that would have the sample code. Currently I'm looking at microchipC.com

Thanks
joel
 

ericgibbs

Well-Known Member
Most Helpful Member
The task that I am required to do is to convert a 4800bps data which has a bit period of 1/56000 seconds, into 2400bps with a bit period of 1/4800s.
hi,:)
What is the format of the in and out data stream.

Is it RS232 serial data at 4800 Baud and 2400 Baud.?
 

Nigel Goodwin

Super Moderator
Most Helpful Member
Hi guys,

The task that I am required to do is to convert a 4800bps data which has a bit period of 1/56000 seconds, into 2400bps with a bit period of 1/4800s.

So essentially, you can think of it has trimming half of the data, and transmitting at a different rate - with a different utilization (or duty cycle if you can call it that).

I'm using Hi-tech C to do the programming, and a PIC18F2550.
I've been looking around for sample codes that does that, but couldn't quite find much. The extent that i have thought thus far, is basically:

Set 1 pin for input
Set 1 pin for output

Take data from input pin and store it in an array using oscillator A.
and output half the array (to half the data) to output pin using a different oscillator B.

Since i'm planning to have a duty cycle of 50%, I was thinking of using a watchdog timer and make the input pin interrupt driven.
You don't use a watchdog timer, that's an entirely different beast used for an entirely different purpose.

Can't help you on C, but there's 16F assembler serial routines (for both software and hardware UART's in my tutorials).

The only problem here is that you're sending data out slower than you're receiving it, so you've got to buffer the data or use handshaking to regulate the incoming data.

There seems no need (or use) for interrupts, I'd probably use a software UART for receiving, and a hardware one for transmitting.
 

joellee

New Member
it is just plain data stream with no special format

as for sending data slower than receiving it...I'm thinking of this...

out of 1 second..

0.15 seconds is used to take in the data (as 4800 bps with a bit period of 1/38400)

then with a slight pause of 0.2 seconds for whatever calculation and storage...

then take about 0.5 seconds to output 2400bps (with bit period of 1/4800) which is about 0.5 seconds..

then 0.15 seconds break until the next input...

I have a very crude C code which doesn't work below, hopefully it clarifies to idea

#include <pic.h>
#include "delay.h"

main(void)
{
#define OUTPUT 0
#define INPUT 1
ADCON1 =7;
bool inputdata[5000];
unsigned input_counter = 0;
TRISA0 = INPUT;
TRISA1 = OUTPUT;

//interrupt happens to signify beginning of data coming in

while(1) //loop forever
{

for (input_counter =0; input_counter+=1; input_counter<5000)

{
inputdata[input_counter] = RA0;
delay(26);//in microseconds
}

for (output_counter = 0; output_counter+=1; output_counter<2500)

{
RA1 = inputdata[output_counter];
delay(2000);
}
}

return 0;
}


thanks guys
 

Pommie

Well-Known Member
Most Helpful Member
bps = bits per second and so the bit time is 1/bps. So, 4800bps has a bit time of 1/4800. You state you will receive a burst every second. How long is that burst?

Mike.
 

Nigel Goodwin

Super Moderator
Most Helpful Member
You appear to be missing the point, and have never told us what the original data is, or how often it is sent. As long as it's send with large gaps between bytes, it's a VERY simple procedure to do it.
 

joellee

New Member
hi pommie,

technically it is 38400 bps (before the microcontroller), just that only the first 10%-15% or so has useful data....
bit 0 to bit 4800 has useful data...
bit 4801 to bit 38400 is all zero
what I want to achieve is 4800bps with
bit 0 to bit 2400 useful data
and 2401 to 4800 all zeros
the microcontroller is supposed to do the job of extracting that 2400 bits out of the original 4800 bits (since I would want to discard much of the GPS data)

Hi nigel
basically, it is GPS data in NMEA 0183 format...
a friend told me that it is UART, which has start and stop bits sort of thing, although i havent verify that myself.

Are there more information i should provide?
 

kchriste

New Member
Forum Supporter
Question:
Why do you have to strip data out of the NMEA string? Doesn't the receiving device do this anyway? That is how most listeners work. They simply decode the incoming data and only pay attention to the relevant strings. They usually are set to 4800 baud which is the standard for NMEA 183 format though some can do different baud rates too.
 

joellee

New Member
Question:
Why do you have to strip data out of the NMEA string? Doesn't the receiving device do this anyway? That is how most listeners work. They simply decode the incoming data and only pay attention to the relevant strings. They usually are set to 4800 baud which is the standard for NMEA 183 format though some can do different baud rates too.
Oh, maybe i should clarify what I am doing...

It is basically a simple system to track a small plane.

GPS receiver > microcontroller > transmitter

at the receiving end

Receiver > Computer

The reason for the microcontroller is to reduce the transmitted data bits... By having less bits (with longer bit periods) i would have less bit error rate.

Hope that clears up some things
 

kchriste

New Member
Forum Supporter
Ok. Well, that simplifies it a bit. Here's how I would do it.

1) Have the PIC wait for the LAT LON identifier in the NMEA string ($GPGGA).
2) Strip out all data except LAT and LON and maybe altitude.
3) Repack and send out with a CRC check sum over radio TX in a NRZ format.
4) Goto step 1
 
Last edited:

joellee

New Member
Ok. Well, that simplifies it a bit. Here's how I would do it.

1) Have the PIC wait for the LAT LON identifier in the NMEA string ($GPGGA).
2) Strip out all data except LAT and LON and maybe altitude.
3) Repack and send out with a CRC check sum over radio TX in a NRZ format.
4) Goto step 1
Yup, I would like to get that done. How do you plan to implement the "wait on" thing?


As in what do the codes of this "wait on" look like? I was actually thinking of recording all the GPS data... and then picking the data I want and plce it in another array, and then transmit that array

I was advised to get a PIC with 2 USART ports, supposing that NMEA data is serial data and retransmitting it at the same format

Thanks for the help
 

AtomSoft

Well-Known Member
hey hey i though when you say 38400 bps its the speed not the data...

If you are getting something at 38400 bps then you are just getting that data at that speed. You are not getting 38400 bits. Thats just the max speed.
 
Last edited:

kchriste

New Member
Forum Supporter
The "wait on" would look like this:
Setup and zero a counter. Use the same counter to index the string $GPGGA.
So when the counter is at 0 look for a $ on the serial port. If you get a match, increment the counter. If not, reset it to zero.
When the counter is at 1 you'll look for a G on the serial port. If you get a match, increment the counter. If not, reset it to zero. etc. etc.. Until the counter equals 6. Once it equals 6 it means the start of the correct NMEA string with the data you seek. Now all you need do is count the characters recieved to find the data you need and store the relevant ones in a buffer. Then transmit in NRZ format once all characters are recieved and the CRC is calculated.
You probably don't need a PIC with two UARTs because you can't send that type of serial data over RF unless you have an RF module with "smarts" which converts it to NRZ type format. What type of RF module are you going to use?
 
Last edited:
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top