Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to turn the baud rate from 9600 to 4800?

Status
Not open for further replies.

giannicamposeo

Newbie level 2
Newbie level 2
Joined
Sep 10, 2013
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Visit site
Activity points
17
Hello.
I have the problem of baud rate in a device gps tracker between the GPS receiver module based on the Mediatek chipset 3329 and the GSM module.
The baud rate output from the GPS module is 9600 bps, while that of Micro / GSM 4800 bps.
How can I reduce the baud rate from 9600 bps to 4800?
Since it is not possible to interact on the micro / GSM, I thought that the banker should interpose an interface between the two sections enterprise engaged in this task.
I thought as a D flip-flop type 74HC74 that divide the frequency by two, then from 9600 to 4800 bps, but what would happen to the string MNEA?

What do you suggest?
Thanks to all
 

You cant just use a d flipflop to reduce baud rate because If you reduce the speed you have to hold the excess datas transmitted in a buffer and what will you do when converting lower to higher baud rate...

Get the matched devices or use a mc between them...........
 

It's worse than that, dividing the baud rate with a flip flop would halve the speed and cause bufferig problems but using one on the data stream would completely destroy it.

I'm not familiar with the chips but assuming the NMEA data is in bursts and there is enough gap between them, you can do it using two UARTs. My preference would be a PIC18 processor as several types have two USARTs on their silicon and plenty of RAM to buffer the incoming data. Basically, you receive at 9600 bauds with one UART, store the characters in a circular buffer (in RAM) and read it back through the other UART at 4800 bauds. It could be as small as a single chip solution. It would work in 'real time' and as long as the number of bytes arriving at 9600 bauds didn't exceed the maximum that can be transmitted at 4800 bauds it should work.

Brian.
 

It's worse than that, dividing the baud rate with a flip flop would halve the speed and cause bufferig problems but using one on the data stream would completely destroy it.

I'm not familiar with the chips but assuming the NMEA data is in bursts and there is enough gap between them, you can do it using two UARTs. My preference would be a PIC18 processor as several types have two USARTs on their silicon and plenty of RAM to buffer the incoming data. Basically, you receive at 9600 bauds with one UART, store the characters in a circular buffer (in RAM) and read it back through the other UART at 4800 bauds. It could be as small as a single chip solution. It would work in 'real time' and as long as the number of bytes arriving at 9600 bauds didn't exceed the maximum that can be transmitted at 4800 bauds it should work.

Brian.

Thanks for the reply.
I measured with the oscilloscope that between a data transmission and the next there is a pause of about 700 msec. Could this be favorable not to destroy data?

Gianni
 

Almost certainly. As long as the gap is as long as, or longer than the data itself, it should work. Reason: the bits at 4800 bauds are twice the length of those at 9600 bauds so it needs twice the time to send it. The forwarding at 4800 bauds can start as soon as the first character at 9600 bauds has arrived and the receiving and transmitting can overlap so if there is time to finish sending the 4800 bauds data before the next 9600 burst starts the buffering will not overflow.

Brian.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top