• AVR Freaks

Hot!RN4678 Baud Rate Sensitivity FYI

Author
jjones11
New Member
  • Total Posts : 7
  • Reward points : 0
  • Joined: 2016/03/24 15:22:31
  • Location: 0
  • Status: offline
2018/09/20 13:27:07 (permalink)
0

RN4678 Baud Rate Sensitivity FYI

This is an FYI for others experiencing issues with the RN4678 Bluetooth device.  I hope this helps with some of the odd issues I've read concerning the RN4678.
 
First of all, I saved a lot of work by buying the RN-4678-PICTAIL.  Using the PICTAIL, in only an hour or so, I knew what had to be done to talk to the chip and configure it for my needs.  I needed to set the baud rate to 912600 instead of the default 115200, and I needed to set the Name so it showed up in the PC's Device List with a friendly name.  So I highly recommend you spring for the PICTAIL.
 
We are using the RN4678 as a Bluetooth "wire" so to speak, i.e. SPP in Classic mode I think it's called.  The point is, we're not Bluetooth experts, so we don't want to be doing a complicated Bluetooth Stack in software; that's a lot of code-space on a PIC.  The PC connects, the PIC sees it, and starts talking, via the RN4678, to the PC.  The RN4678 handles all the Bluetooth stuff for us.
 
We use Uart3 of a dsPIC33EP512GM710 running at 70 MHz (yes, it's a 70MHz PIC).  We hook up the PIC's RTS/CTS to the RN4678's CTS/RTS, and the PIC's TxData/RxData to the RN4678's RxData/TxData.  It may be obvious to most, but I point out the crossed PIC/RN4678 signal-names;  RTS-to-CTS, and TxData-to-RxData.  Uart-driven devices are not always consistent in their naming-conventions.  It all depends on if you're looking at the pins from the PIC point-of-view, or the device's point-of-view.
 
On the PIC, we set the Uart to 115200 baud, configure the RN4678 for 912600 Baud, switch the Uart to 912600 baud, then we execute a do-forever loop that simply sends the '&&&' command to Enter Command Mode, followed by the '---' command to Exit Command Mode, and verifying the responses to both commands as we go.  I use Uart1 as a Debug-Out Uart to a terminal window on my PC so I can watch the loop progress.  I found that the loop would fail one of the commands every few (5 or 6) loop iterations.  If everything is working correctly, it should NEVER fail, but I was getting MANY failures.  This is not good!
 
So here's the analysis:  I configure the PIC to use the internal oscillator so I can program it for almost ANY clock frequency.  Everything else on our PIC-system uses 912600 Baud with a 70MHz PIC clock.  But - at a 70MHz clock, the PIC cannot generate exactly 921600 or 115200 baud rates at the Uarts.  The Uart's BRG is not hi-res enough to beat the PIC-clock to a precise baud rate.  The actual bauds with our 70MHz clock are 921052 (Err of -548) and 115131 (Err of -69).  In all our past projects (several with both a 33F and 33E PIC), that amount of baud error was acceptable and everything operated fine... but NOT the RN4678.
 
The closest PIC clock (without going over 70 MHz) that produced exact baud rates of 912600 and 115200 is 58982400.  This PIC clock produced 0 baud Error at both baud rates... and the RN4678 is happy as a clam.  We experienced no more dropped loop-iterations.  So, apparently, the RN4678 is VERY sensitive to a mismatched baud, at least at the higher rates.
 
Just remember - when configuring your UART, the desired baud is not necessarily the baud you actually get, and the device you're talking to (via the UART) may not tolerate the difference, even a minuscule difference.
 
A couple years ago, I had to write a tool that beats PIC-clock frequencies against Uart baud rates to reveal exactly what's going on.  It outputs the precise maximized PIC clock such that we get our desired baud rates, desired baud versus actual baud, the amount of baud error, and the magic-register settings to achieve the PIC clock and Uart baud rates.  This single little trick (tweaking the PIC-clock) has saved our butts in UART-land, and CAN-land (another baud-sensitive protocol), several times.
 
I'm just sayin'.
 
jjones
 
post edited by jjones11 - 2018/09/20 21:11:23
#1

4 Replies Related Threads

    jjones11
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2016/03/24 15:22:31
    • Location: 0
    • Status: offline
    Re: RN4678 Baud Rate Sensitivity FYI 2018/09/20 21:10:36 (permalink)
    0
    After posting the above, and doing some hard thinking about it... I think/doubt that the RN4678 is THAT sensitive.  I mean although it's running like a champ at full speed at a perfect 921600 baud (by tweaking the PIC clock), the original setting was 921052, and that's only a baud error of less than .06 percent!  I would think that would be fine.

    I guess I'll be breaking out the scope again and looking at Tx/Rx pull-up/downs, signal shape/quality etc., to verify everything is as it should be.
    jjones
     
    #2
    jjones11
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2016/03/24 15:22:31
    • Location: 0
    • Status: offline
    Re: RN4678 Baud Rate Sensitivity FYI 2018/10/02 12:51:50 (permalink)
    5 (1)
    Nope... the baud rate issue is definitely confined to the RN4678.  Baud rate, at least at 921600 baud, has to be very close, if not exact.  Why is that Microchip?  The documentation yields nothing about accuracy or permissible baud operating error!

    Also NOT in the RN4678 Command Reference manual is the fact that different commands take different amounts of time to respond.  I had to use a 32-bit PIC timer (clocked at the PIC FCY rate) to accurately measure the time from issuing a command to getting a response.  Using this method, you can get accuracy to within the FCY resolution (nanoseconds).  To measure the response time, I issue a command first, then record the 32-bit timer ticks as the start time, wait for the response, then record the timer tick stop time, and convert the difference to uSecs or mSecs, whichever is appropriate.  In a real-time system, you can't afford to spin-forever waiting for a response, so you need an intelligent timeout.  But you can't set a reasonable timeout unless you know how long a command should typically take.  Shame on you Microchip!  I shouldn't have to trial-and-error my way through this chip.  DOCUMENT IT!
     
    I didn't check all commands, just the 5 or 6 that I needed to use.  For example, it takes 7 mSecs to get a response to the Enter "$$$" and Exit "---" Command Mode commands, 8 mSecs to get a response to the Get Name "GN" command, a whopping 107 mSecs to respond to the Set Name "SN,abcdefgh" command, etc... you get the idea.  For general usage, I set response-timeouts at 2x the measured response times.  Either it responds before the timeout, or I declare an error.  This way, it runs (commands/responses) at its fastest possible capacity.
     
    The spec states 475 mSecs if you reset/reboot or power-up the device, and that's pretty accurate... and it's the ONLY wait-time they actually specified.  I set my timeout to 600 mSecs on that one.
     
    Good luck.
    jjones
     
    #3
    EwenF
    Starting Member
    • Total Posts : 65
    • Reward points : 0
    • Joined: 2003/11/07 12:38:00
    • Location: New Zealand
    • Status: offline
    Re: RN4678 Baud Rate Sensitivity FYI 2019/05/22 20:44:15 (permalink)
    0
    Does RN4678 have an undocumented command that allows baud rate to be changed temporarily?
    That is possible with RN42 which uses SU,<baud> for permanent change but also has U,<baud>,<mode> for temporary change.
    RN4678 uses U command for a different purpose but I wondered if there's another command
     
    #4
    jjones11
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2016/03/24 15:22:31
    • Location: 0
    • Status: offline
    Re: RN4678 Baud Rate Sensitivity FYI 2019/05/24 04:44:18 (permalink)
    0
    No, no other baud-related command.  It's U-command is:
    "U,<Z,1-8>Command U removes one or more devices from the linked device list. It expects one input parameter. The linked device list can be accessed by issuing command Y.
    If the input parameter is letter Z, then all devices are removed from the linked device list.
    The input parameter can also be a single digit from 1 to 8, corresponding to any of the eight devices in the linked device list to be removed."
     
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 4.5