Anyone have experience using the RN4020 module? Any hiccups or anything to be aware of?

Also, it is my understanding that, as long as you use the module unmodified, no addtional FCC testing or approvals are required. Is this correct?

Edit: I'll be using it PIC to PIC, not PIC to PC or mobile device.

 

Sorry I have no experience to share.

I have yet to hear about the FCC tracking down wild bands of roving bluetooth free booters,so if this is for your own enjoyment got for it.

However, I suspect you have bigger interests in mind, such as a commercial product. I'd hit up Microchip and see how wide their FCC authorization spreads.

 

The documentation for RN4020 leaves a lot to be desired. I have to read every paragraph at least 3 times. Not many examples.

 

I have not used the microchip module but I have used one of those HC-06 modules from eBay. Very easy to implement. A lot cheaper too I bet.

 

Hi,
I haven't used the rn4020 (sorry I'm giving you as much info as everyone else!) I do have one on the desk ready to try though. I have used a Rn42 though, was quite easy even for a fool like me to get going, roving networks do a datasheet for the commands which is good to go with the data sheet for the Rn42.

Do let us know how you get on, the 4020 is half the price of 42 here in UK, about £4.50 I think, rs do list it as a development module though (not sure what that means?)

When I've finished building the house and the baby's bigger maybe I'll get to it

Cheers Geoff

 

Somewhat related Joey, MCP recommends to make available the 4 specific pins used in the factory for tests in case the module has to be checked. It seems that an approval could be needed requiring a such a test.

/Edit

Sorry. The above pertains to the RN42, not to the RN4020. My bad.

/Edit

 

Neat little unit. I don’t believe you need to worry. Unless you built the chip.

 

The original project that I was going to use the RN4020 went by the wayside, but I am now working on another project -- this one integrates the RN4020 into an existing design with a PIC18F85J90.

So far, I am getting the RN4020 initialized and connect to my Android. I can read and write the built-in characteristics. Things look good.

Most annoying is the command interface -- it's all through ASCII commands and handshaking is done via returned messages like "AOK", "ERR", and such. Unfortunately, I cannot use any blocking functions to write the commands and wait for the response, so I am building what looks like is going to be a huge state machine to send commands and react to parsed responses. And, of course I am doing it in .asm.

This is how I have fun. Seriously.

 

The original project that I was going to use the RN4020 went by the wayside, but I am now working on another project -- this one integrates the RN4020 into an existing design with a PIC18F85J90.

So far, I am getting the RN4020 initialized and connect to my Android. I can read and write the built-in characteristics. Things look good.

Most annoying is the command interface -- it's all through ASCII commands and handshaking is done via returned messages like "AOK", "ERR", and such. Unfortunately, I cannot use any blocking functions to write the commands and wait for the response, so I am building what looks like is going to be a huge state machine to send commands and react to parsed responses. And, of course I am doing it in .asm.

This is how I have fun. Seriously.

Fun? If were you, I would set the record for enjoying 5pm on Friday more than anyone else on earth.

 

I have not used the microchip module but I have used one of those HC-06 modules from eBay. Very easy to implement. A lot cheaper too I bet.

I just bought an HC06 but haven't had time to do anything with it. Do you have any PIC-based code to share?

From what I've read, it seems like the HC-06 works a lot like the AT command-lines @joeyd999 is describing for the microchip device.

 

Fun? If were you, I would set the record for enjoying 5pm on Friday more than anyone else on earth.

Spent the weekend coding. Much fun!

 

Spent the weekend coding. Much fun!

Too bad for you! I got to transplant shrubs in the rain. Clay, shale, mud - oh, the joy!

 

Too bad for you! I got to transplant shrubs in the rain. Clay, shale, mud - oh, the joy!

You and I have very different ideas of "fun"...

 

The things that you describe ... Both look like fun to me

 

The default 115K baud, on the receiver side, is killing me! Dammit, I'll make it work, though. Setting a lower baud is cheating, IMHO...

 

115K baud is one character every 86 us. Looks very slow to me. How fast is your PIC running?

 

115K baud is one character every 86 us. Looks very slow to me. How fast is your PIC running?

The the PIC is running 8 mhz. That's not my problem, though. I've got a high priority interrupt that runs periodically and consumes more than two character times. For reasons I won't explain, these things need to happen within the interrupt, and not outside in the main code.

The receiver is also running high priority. My solution is likely going to be to check the receiver interrupt flag within the other service routine and process it if necessary.

The other alternative is to just change my clock speed -- but this is an existing application and I have reasons for not wanting to make major changes.

Alternatively, I can just change the baud of the RN4020, but like I said, that's cheating.

 

Here's the first part of my code to parse responses. It looks for the 'standard responses' and sets a flag if one of the standard responses was received. If the response is non-standard, it sets another flag to indicate it, for further parsing later (the parsing method is determined by the command sent that evoked the response).

;*****************************************
;** BTPRCV -- Process Bluetooth receiver **
;*****************************************

btprcv    retbc    fbtinit            ;don't receive if in initialzation

    clrf    btsresp,1        ;clear standard response flags

    movlf    fsr0h,high btrcvbuff    ;point to receiver buffer
    movff    btrhead,fsr0l        ;  and index to next character

btplp    rcall    rxbyte            ;receiver byte available?
    retz                ; z if none

    movwf    indf0            ;save character at current position
    movlw    '\r'            ;ignore return characters
    cpfseq    indf0
    movf    postinc0,w        ;get back in w, and update pointer
    movff    fsr0l,btrhead        ;save new head position

    xorlw    '\n'            ;new character a line feed?
    bnz    btplp            ;no, get some more characters, if available  

    movlfb    btrhead,low btrcvbuff    ;reset btrhead for next message

;parse for common messages
;if common response not matched, indicate (likely) parameters returned from RN4020

    bsf    btsresp,0,1        ;set 1st bit in standard response flags

    movdf    tblptr,btcmes        ;tblptr -> possible responses (\n separated, \0 terminated)

btplp0    lfsr    0,btrcvbuff        ;fsr0 -> point to head of response buffer
  
btplp1    tblrd    *+            ;get next character from list of responses
    movf    tablat,w        ; into w reg
    bz    btpnmf            ;if 0, no response matched

    cpfseq    postinc0        ;test against charcter in response buffer
    bra    btpnom            ;!= means no match, skip to next response

    xorlw    '\n'            ;new line character?
    bz    btpmat            ;yes, we have found a match

    bra    btplp1            ;keep testing characters till match

;no match of current response, skip ahead till /n or /0

btpnom    clrc                ;roll to next response
    rlcf    btsresp,f,1

btplp2    tblrd    *+            ;get next character from list of responses
    movf    tablat,w        ; into w reg
    bz    btpnmf            ;zero of no match found

    xorlw    '\n'            ;new line character?
    bnz    btplp2            ;loop till \0 or \n

    bra    btplp0            ;and test against next response

;match found, response bit set

btpmat

;match not found, non-standard response bit set

btpnmf

    return

btcmes    db    "AOK\n","ERR\n","Bonded\n","Secured\n","Connection End\n","Reboot\n",'\0'

Edit: For the umpteenth time! Please, someone, tell me how I set tab width within the code tags! I refuse to change my tabs to spaces.

 

The the PIC is running 8 mhz.

Certainly, you have room for increasing it.

The receiver is also running high priority. My solution is likely going to be to check the receiver interrupt flag within the other service routine and process it if necessary.

If you find a good "middle" where you can put the check it certainly will work, but then changing your "big thingy" code will move this point back and forth in time and may disturb timing.

You can try re-saving your shadow registers and enabling high-priority interrupts before entering your "big thingy" then restoring it all back at the end of it. This way your Bluetooth interrupts can interrupt your "big thingy". If your "big thingy" has critical sections which cannot be interrupted, then you can disable the interrupt around these sections.

 

The things that you describe ... Both look like fun to me

What's really super, duper fun is drinking a few pints while writing some really complicated code. That's what I'm doing now. I may have to pop off into the off-topic sub-forum for awhile...