On High Interrupt
Save System

If RCSTA.OERR = 1 Then  'BIT1..if over run error then flush RXD buffer
    If RCSTA.FERR = 1 Then  'BIT2..framing error(can be cleared by reading RCREG register And receiving Next valid Byte)
        RCSTA.CREN = 0
        RCSTA.CREN = 1  'BIT4 ENABLES RECEIVER
        char = RCREG  '1
        char = RCREG  '2
        err = 1  'ERROR
    Endif
Endif

Hi C.
One idea. You test for OERR but then require that FERR is also set before you fix the UART. You are unlikely to get a framing error if your baud rate is correct. In this code, if you get an overrun error without a framing error (likely), you will never get to the required fixup code and the UART will be kaput. You don't need to reset the UART on a framing error, it will still continue to receive characters and generate interrupts (but you have to discard the data). Treat the errors as separate with separate fixes.

A thought for you: Once I get a serial link set up, I never turn it off. I always receive every character sent with the appropriate error checking/recovery. The problem with on and off is that you don't know where you are in the input stream when you turn it back on. Clearly a good error detection / recovery scheme will handle that (as it must when you are powering up or after a uC reset) but I just don't like jumping into a stream mid-character. My solution is to have a flag to indicate when I don't want to process any characters. Receive/error check/recover as normal then check the flag to see if the received character should be processed or discarded. That way, a simple flag turns the data stream on and off. In your case, enabling the data processing would also begin looking for the '$'. Such a scheme also allows you to monitor the presence and integrity (no hardware error flags) of the stream continuously, even if you are not processing the data.

Why have any delays at all? Get a buffer full, parse and process it, use that data then get back to the top and wait for the next buffer full. Mixing real-time processing needs (receiving from a UART with no flow control) with blocking delays is pretty much guaranteed to drive you crazy, especially when you try to get lucky with just-in-time timings. Ask me how I know these things.

While we're at it. Keep in mind that any test you send to the terminal is likely using a blocking delay. Most simple implementations write to TXREG then poll a flag to see when that character has been sent and the UART can take another. At 9600 baud, each character is about 1ms. So saying 'ERROR!' bogs your system down 60ms more or less. Note that the simulator may not take the time to transmit into account but just put the characters up on the window adding to your timing woes between sim and hardware. I don't know how Oshensoft does it but have been bit by that on other systems.

Just my .02
Good luck!

Hi JT,
I'm out of my depth, so my answer may seem limited!

1/ Regarding OERR and FERR, as 'J' advised me to [ OR ] them. Does this change your question, and solution?
See attachment:

2/ Regarding 'jumping into a stream' There is a [ If BAUDCON.RCIDL = 1 Then 'Avoid framing error-BIT6 ] to check that there is a character. Again does this change your question and solution (Which for me is too difficult)

3/ Regarding delays: I added some to allow the process, and don't know how to set the length, and I added one so I can watch it in the simulator. I intend to remove them by experiment as I get each section working.
"is pretty much guaranteed to drive you crazy" To late


4/ The last paragraph, and in general, I hoped I could write an INTERRUPT PARSE routine, but it seems I am incapable of it. As too much time and effort has been spent over the years from me and other forum members, on this project, I have to keep trying, till I get some results. It's actually almost working, even though it may be a mess.
Thanks, C.

 

1) In the code in #201, J wrote:
If RCSTA.OERR = 1 Or RCSTA.FERR = 1 Then
which does indeed OR the two flags i.e. if either is set then fix the UART and re-sync the data when you get the next '$'. Your code effectively ANDs the two flags which means that BOTH errors must occur to fix the UART, an unlikely occurrence. That's the problem.
2) As long as your UART code detects OERR and resets the UART and also detects FERR and handles that (read RCREG and ignore the data is all it takes), you should be OK. You can reset the UART on either flag if you want, just be sure it is an OR function, not AND as you wrote it. RCIDL would be superfluous in this application, I think. It indicates whether the receiver is idle so that you can set up for 'wake up on character' without being in the middle of a character.
3) I personally would make the only 'delay' that which occurs after you are done processing and there is nothing else to do but wait for the next sentence.
4) It's OK to do it like you are doing it. Let the UART interrupt fill the buffer then signal (by a flag) that the buffer is full then stop receiving. Process the buffer then restart the UART with the expectation that you might generate some errors while it gets re-synced to the stream. As I indicated, you need good error handling anyway and each sentence begins with '$' so it should work OK.
Good luck!

 

1) In the code in #201, J wrote:
If RCSTA.OERR = 1 Or RCSTA.FERR = 1 Then
which does indeed OR the two flags i.e. if either is set then fix the UART and re-sync the data when you get the next '$'. Your code effectively ANDs the two flags which means that BOTH errors must occur to fix the UART, an unlikely occurrence. That's the problem.
2) As long as your UART code detects OERR and resets the UART and also detects FERR and handles that (read RCREG and ignore the data is all it takes), you should be OK. You can reset the UART on either flag if you want, just be sure it is an OR function, not AND as you wrote it. RCIDL would be superfluous in this application, I think. It indicates whether the receiver is idle so that you can set up for 'wake up on character' without being in the middle of a character.
3) I personally would make the only 'delay' that which occurs after you are done processing and there is nothing else to do but wait for the next sentence.
4) It's OK to do it like you are doing it. Let the UART interrupt fill the buffer then signal (by a flag) that the buffer is full then stop receiving. Process the buffer then restart the UART with the expectation that you might generate some errors while it gets re-synced to the stream. As I indicated, you need good error handling anyway and each sentence begins with '$' so it should work OK.
Good luck!

Hi JT,
We may get the answer to the 'OR' question here, but I've also asked on another forum.

As mentioned there is a DATASWITCH that switches between 3x sentences beginning with a $ and ending with a W. One of them is onboard and from the 18F4431 Incremental encoder, one for the GPS and one sent to the PIC from a computer terminal betweem two radios. It is this one that appears to be blocked by the other two as they start coming in, as shown in the #199 image. I've had this before!
Thanks, C.

 

We may get the answer to the 'OR' question here, but I've also asked on another forum.

I believe you'll find that I am correct on this one. The RX interrupt handler you show in #197 requires that both OERR and FERR be set to effect any remedies. There is no guarantee that will occur. If you get an overflow error without a framing error the UART will stop interrupting. The interrupt handler in #201 is much closer to what you want as it does not require that BOTH flags be set to fix the UART.

As mentioned there is a DATASWITCH that switches between 3x sentences beginning with a $ and ending with a W. One of them is onboard and from the 18F4431 Incremental encoder, one for the GPS and one sent to the PIC from a computer terminal betweem two radios. It is this one that appears to be blocked by the other two as they start coming in, as shown in the #199 image. I've had this before!

Yeah.. I forgot that you are multiplexing the streams with an external switch. No worries BUT that means that your UART error detection/recovery must be robust. Switching between several streams virtually guarantees UART errors will occur during the switch. Your switching code should:

• Disable the UART and the interrupt
• Initialize the buffer
• Switch the input
• Re-enable the UART
• Clear any errors
• Clear RXIF
• Re-enable the interrupt

I'd put it all in the init UART subroutine and call it when you start up or switch the inputs. That way the UART and buffer starts from the same state every time.
Have fun.

 

@JohnInTX, he fixed that code in #197 a while back, and is using a logical OR now to test for either flag, upon which he resets the UART. Not the cleanest way, but it will work since he is switching input streams to the UART.
You can see the corrected code in #185, #186 after I pointed out the problem you saw in #201. I don't know why he posted incorrect code vs what he had posted earlier.
See my post #179, I pointed out the same issue way back when....

 

@JohnInTX, he fixed that code in #197 a while back, and is using a logical OR now to test for either flag, upon which he resets the UART. Not the cleanest way, but it will work since he is switching input streams to the UART.
You can see the corrected code in #185, #186 after I pointed out the problem you saw in #201. I don't know why he posted incorrect code vs what he had posted earlier.
See my post #179, I pointed out the same issue way back when....

Thanks for that. Trying to keep up! I’ll wait and see what shakes out. Thanks again.

 

@JohnInTX, he fixed that code in #197 a while back, and is using a logical OR now to test for either flag, upon which he resets the UART. Not the cleanest way, but it will work since he is switching input streams to the UART.
You can see the corrected code in #185, #186 after I pointed out the problem you saw in #201. I don't know why he posted incorrect code vs what he had posted earlier.
See my post #179, I pointed out the same issue way back when....

Hi S,
I know it's dangerous to copy and paste sections of programs, but this is the only way I can move forward sometimes, and I don't always spot my mistakes, this is why I made a step backwards.

Here is the latest Program, where there may be other mistakes, sorry.
This one works with 2x of the sentences, but not the transmitted one, and I'm trying to figure out why.
C.

 

I believe you'll find that I am correct on this one. The RX interrupt handler you show in #197 requires that both OERR and FERR be set to effect any remedies. There is no guarantee that will occur. If you get an overflow error without a framing error the UART will stop interrupting. The interrupt handler in #201 is much closer to what you want as it does not require that BOTH flags be set to fix the UART.

Yeah.. I forgot that you are multiplexing the streams with an external switch. No worries BUT that means that your UART error detection/recovery must be robust. Switching between several streams virtually guarantees UART errors will occur during the switch. Your switching code should:

• Disable the UART and the interrupt
• Initialize the buffer
• Switch the input
• Re-enable the UART
• Clear any errors
• Clear RXIF
• Re-enable the interrupt

I'd put it all in the init UART subroutine and call it when you start up or switch the inputs. That way the UART and buffer starts from the same state every time.
Have fun.

Hi JT,
I wasn't disputing you, but I did have issues, before with Oshonsoft, and my understanding of logical OR and the other one?

I think the latest program works in the order you suggest.

I don't quite understand this line: "I'd put it all in the init UART subroutine and call it when you start up or switch the inputs." Unless you mean the CODE just after MAIN should be put in the INTERRUPT routine? I was trying to have as little in the INTERRUPT as possible, after this was suggested. I don't actually know what a 'too big' INTERRUPT is?
C.

 

Flaw in your logic again. In the code:

If PIR1.RCIF = 1 Then
        char = RCREG
        If char = "$" Then
            rxpsn = 0
            buf_fill = 1
        Endif
        If buf_fill = 1 Then
            buf(rxpsn) = char
            If rxpsn < 50 Then
                rxpsn = rxpsn + 1
            Endif
        Endif
        If buf(0) = "$" And char = "W" Then
            RCSTA.CREN = 0  'INTERRUPT DISABLED
            PIE1.RCIE = 0  'DISABLEs EUSART RECEIVE INTERRUPT
            buf_fill = 0
            buf_done = 1
        Endif
Endif

if rxpsn is 50 or greater, you do not detect the error and clear the buffer and pointers. The way it is written, you will overwrite memory/variables in other positions without a check on the validity of rxpsn.
You MUST validate all data when capturing data, because something will eventually go wrong. Especially true when switching streams, you may get a string longer than 50 characters.

 

I realize I'm late to the party and haven't read all of the suggestions and advice. But I did want to point out the logic error in the code you posted in #197, the latest at the time. I don't want to change any path you're already on and muck up the excellent help you're getting from others but I am happy to answer specific questions:

I don't quite understand this line: "I'd put it all in the init UART subroutine and call it when you start up or switch the inputs."

With the 3 streams going all the time, UART start up and switching channels is problematic. As I indicated above without some sort of external synchronization or control, you are virtually assured of UART errors whenever you start up or change channels with the UART active. Your start up code is somewhat haphazard. You enable the receiver and interrupts BEFORE you call Hseropen. During that interval, you're likely to generate UART errors.

Your code seems to handle some of this by turning off the RX and interrupt enable when you get a successful buffer fill but it's still kind of haphazard. What I was referring to in the post is this:
Assume that whenever you enable the port and/or switch channels, you will get a UART full of crap because of the incoming streams hammering at it before you get it fully configured.
If that must be the case you have to init the UART and change channels carefully. The easiest way to do that is to write ONE main (non-interrupt) subroutine that takes as a parameter the channel number and brings up the UART from an unknown state to a known good state with the buffer initialized and ready to receive. In that subroutine, carefully order the operations. The sequence in my #204 is a good starting point. Note that that sequence does a full shutdown of the UART, sets up the channel then restarts the UART at 9600,N,8,1, clears all error flags, then enables interrupts to start. When properly written the routine should bring up the UART from any condition it may be in and leave it ready to receive the selected stream.
All UART control from main is done through this subroutine e.g. original init and channel changing.

The benefit of this approach is that you know exactly how the UART will be set up at any given time because there is only one routine that does it. By scattering the init peices through the code and replicating parts of it for channel changes etc, you get a 'different' UART at different times in the execution of the program. Such things are to be avoided. Note also that if you discover that you need to add something or rearrange the init sequence, you do that in one place so it works for every instance.

Finally at the risk of fouling the waters more, the error handling in the interrupt routine is OK but you should do 2 things:
1) on any error, completely reinitalize the buffer - either error will result in a corrupt sentence received so you really don't know what to process from there. Clean up and get ready for the next '$'
2) at the end of the error fixing, GOTO to the end of the interrupt routine instead of proceeding to If PIR1.RCIF = 1... The reasoning is that when you processed the error(s), you processed the character(s) that generated them and no further processing is warranted. Your buffer should be ready to go on the NEXT interrupt, hopefully with no further errors but if so, it will keep processing the errors and discarding characters read until the stream clears up and you start getting good chars again.

Thanks for your indulgence. I'll go sit down now
Good luck!

 

Hi S and TX,
I get the sense, that all of a 'good' INTERRUPT/PARSE routine is in my program, but not quite in the correct order.

I don't alway get the names of things correct, in the replies e,g, buffer-UART-etc, and sometimes forget good advice, so even though I spend a long time trying, I don't always go in the right direction.

Does everybody agree that the INTERRUPT below looks ok? (I understand the >50 concerns)
==============================================

On High Interrupt
Save System

'BIT1..if over run error then flush RXD buffer
'BIT2..framing error(can be cleared by reading RCREG register And receiving Next valid Byte)
If RCSTA.OERR = 1 Or RCSTA.FERR = 1 Then
    RCSTA.CREN = 0
    RCSTA.CREN = 1  'BIT4 ENABLES RECEIVER
    char = RCREG  '1
    char = RCREG  '2
    err = 1  'ERROR
Endif
   
If PIR1.RCIF = 1 Then
        char = RCREG
        If char = "$" Then
            rxpsn = 0
            buf_fill = 1
        Endif
        If buf_fill = 1 Then
            buf(rxpsn) = char
            If rxpsn < 50 Then
                rxpsn = rxpsn + 1
            Endif
        Endif
        If buf(0) = "$" And char = "W" Then
            RCSTA.CREN = 0  'INTERRUPT DISABLED
            PIE1.RCIE = 0  'DISABLEs EUSART RECEIVE INTERRUPT
            buf_fill = 0
            buf_done = 1
        Endif
Endif
Resume

================================================================
I'll re-check your sequence in #204, but I'm reluctant to mess about with the existing CODE too much, as we've spent a long time getting this far. If I can work it out, I'll try to have a go at it.

I tried to make a RING BUFFER, but couldn't get it to work, so I took this direction. I'm simply not up to it.

From watching the simulator, and putting in erronious $sentences, I can see some of the errors, that you predict, but the CODE appeared to cope with them, and ignore them till the next $ arrived at the UART. Anything above the normal message length gets overwritten after the $ untill the W. There is a Buffer clear routine by 'E' but I found is wasted time and didn't appear to be needed.
Thanks for your detailed replies.
C

 

Hi,
After a couple of days staring at the wall with a pack of Aspirin, I've thought of a way that I dare try againI've got SKELETON in the name so I can find it again!

If we use JTs approach and using his bullet points #204, here is a program with hopefully only the correct sections left, and I'll try to fill the blanks, in steps as we go along.

I've commented out the [<50 IF-ENDIF ], but something needs to replace it.
C.

 

If we use JTs approach and using his bullet points #204, here is a program with hopefully only the correct sections left, and I'll try to fill the blanks, in steps as we go along.

Hold on there, cowboy. I wasn't suggesting yet another rip out and rewrite, just observing that some structure to what you are doing would make things easier to manage as you debug this thing.

Avoid the temptation to do massive re-writes in hopes of magically fixing the underlying, unknown cause(s) of your troubles. That takes a lot of time (and aspirin ) and most importantly, you never know whether you have fixed the underlying issues because you 1) don't know what they are and 2) not knowing that, have no way of effectively testing to see if you have fixed the problems and 3) your new code likely introduces brand new bugs that cause new problems or worse, change how the original problem looks. It's like herding cats - you are never really in command of the situation.

I would recommend detailed debugging on the current code, using it as a tool to drill down to the problem fix it then test to ensure the fix is solid. When you finally get it working, archive it THEN you can proceed to streamlining and organizing before you proceed with more features.

Think about something like this:
IIRC, you are having problems with the REMOTE stream from the other PIC, correct? Before tackling that, I would lock it down to one of the other 'good' channels and use it for testing.
@sagor noted an issue with your buffer. You can get that fixed with one channel active.

Get as much done with the error detection/correction using that one channel.
You don't have to do much parsing at this point, just look for the buffer getting filled with $->W messages and call success at this point. A simple blink of an LED would be a good indicator.

Switching active streams is error prone. Force some errors:

One way would be to monitor the buffer filling flag (indicating $ was found and it's in the middle of a sentence) then switching to another channel for a few ms then back to the original channel. That should be enough to emulate channel switching in the middle of a stream and generate some errors. Observe how the interrupt routine detects and fixes that error. Do nothing else until you can ensure that the code recovers from switching in the middle of the stream.

Force an overrun error (OERR) by again monitoring the filling buffer flag to ensure that you are in the middle of a sentence then turn OFF RCIE for a few ms. That will force OERR to be set - you haven't processed characters fast enough. When you turn RCIE back on, ensure that the interrupt code detects and fixes the overrun error, discards any partially filled buffer and is ready for the next $.

Force framing errors (FERR) by changing the baud rate on the PIC. As before, ensure that the interrupt code detects and handles them by resetting the buffer each time and waits for the next $.

Don't proceed until ALL of this is working i.e. you can bang-hammer on the UART input in any way you can think of and guarantee that it will recover gracefully and be ready for the next sentence.

If you want to proceed along these lines or some other structured debugging approach, we can help. I don't see you getting to success any other way.

Thoughts?

 

Hold on there, cowboy. I wasn't suggesting yet another rip out and rewrite, just observing that some structure to what you are doing would make things easier to manage as you debug this thing.

Avoid the temptation to do massive re-writes in hopes of magically fixing the underlying, unknown cause(s) of your troubles. That takes a lot of time (and aspirin ) and most importantly, you never know whether you have fixed the underlying issues because you 1) don't know what they are and 2) not knowing that, have no way of effectively testing to see if you have fixed the problems and 3) your new code likely introduces brand new bugs that cause new problems or worse, change how the original problem looks. It's like herding cats - you are never really in command of the situation.

I would recommend detailed debugging on the current code, using it as a tool to drill down to the problem fix it then test to ensure the fix is solid. When you finally get it working, archive it THEN you can proceed to streamlining and organizing before you proceed with more features.

Think about something like this:
IIRC, you are having problems with the REMOTE stream from the other PIC, correct? Before tackling that, I would lock it down to one of the other 'good' channels and use it for testing.
@sagor noted an issue with your buffer. You can get that fixed with one channel active.

Get as much done with the error detection/correction using that one channel.
You don't have to do much parsing at this point, just look for the buffer getting filled with $->W messages and call success at this point. A simple blink of an LED would be a good indicator.

Switching active streams is error prone. Force some errors:
======================================================================
One way would be to monitor the buffer filling flag (indicating $ was found and it's in the middle of a sentence) then switching to another channel for a few ms then back to the original channel. That should be enough to emulate channel switching in the middle of a stream and generate some errors. Observe how the interrupt routine detects and fixes that error. Do nothing else until you can ensure that the code recovers from switching in the middle of the stream.

Force an overrun error (OERR) by again monitoring the filling buffer flag to ensure that you are in the middle of a sentence then turn OFF RCIE for a few ms. That will force OERR to be set - you haven't processed characters fast enough. When you turn RCIE back on, ensure that the interrupt code detects and fixes the overrun error, discards any partially filled buffer and is ready for the next $.

Force framing errors (FERR) by changing the baud rate on the PIC. As before, ensure that the interrupt code detects and handles them by resetting the buffer each time and waits for the next $.

Don't proceed until ALL of this is working i.e. you can bang-hammer on the UART input in any way you can think of and guarantee that it will recover gracefully and be ready for the next sentence.

If you want to proceed along these lines or some other structured debugging approach, we can help. I don't see you getting to success any other way.

Thoughts?

Hi JT,
"Thoughts?" Overwhelmed, but thanks for your reply.

"you are having problems with the REMOTE stream from the other PIC, correct?" No, I'm having problems with the REMOTE from the radio.

The other two channels: GPS and 18F4431 (other PIC on PCB) are being received, parsed, transmitted and received in a computer Terminal after being programmed ok. Switching between those two channels, is fine.

I've been debugging, using the Oshonsoft simulator, and sending erroneous sentences, that so far have been successfully filtered out by the program. #209

This reply goes down your message upto the ======================== that I added into it.
I think any more, and it will be more confusing. I can only work in small steps.

Looking at the #209 program, and your suggestion of a 'UART GOSUB' How much of #209 should be in that GOSUB?
C.

 

------------------------------------------------------------
$GNRMC,123519,A,4807.038,N,01131.000,W,022.4,084.4,230394,003.1,W*6A?
$REMOTE,1100,1200,1300,1400,1500,1600W,? (Nonsense, just for testing)
$QEIDEG,123,?
----------------------------------------------------------------------

Which one of these (from post #7) is from the radio and not working? The $REMOTE ? I ask because the code you posted expects the sentence to end with a 'W' and $QEIDEG doesn't in the example. Is the example correct?
What happens when it fails?
I'm trying not to overwhelm you so take it a bit at a time. Most of what I posted were suggestions not knowing exactly where you are in the process. Take or reject as appropriate. I do believe that you still have problems in the error handling in the interrupt routine and can help with that if you want.

 

Which one of these (from post #7) is from the radio and not working? The $REMOTE ? I ask because the code you posted expects the sentence to end with a 'W' and $QEIDEG doesn't in the example. Is the example correct?
What happens when it fails?
I'm trying not to overwhelm you so take it a bit at a time. Most of what I posted were suggestions not knowing exactly where you are in the process. Take or reject as appropriate. I do believe that you still have problems in the error handling in the interrupt routine and can help with that if you want.

Morning JT,
That's fine.
Since the example in #7, the program has been updated and changed many times. The reason, the memory of the 18LF4620 is a bit short, so saving any is helpful. At the #7 time the program used sentences starting with $ and ending with either ? or LF, where the $NMEA sentence was 70ish digits long, I found that as we only need (shown in red) up to the W worked, I changed to that.

While using the Simulator all of the $Sentences worked, but when 'live' the REMOTE through the radio didn't. I'm running a series of TX RX radio tests at the moment, to help find the fault.

I don't really understand error handling!, apart from OERR and FERR a little. I am able to READ each of the sentences after the DATASWITCH using a computer terminal.

Thanks,
C.

 

Since the example in #7, the program has been updated and changed many times. The reason, the memory of the 18LF4620 is a bit short, so saving any is helpful. At the #7 time the program used sentences starting with $ and ending with either ? or LF, where the $NMEA sentence was 70ish digits long, I found that as we only need (shown in red) up to the W worked, I changed to that.

Makes sense now, thanks.
Let us know what you find running the actual radio. Question: is there a time delay between sentences from the radio?
Error handling: one thing you are missing in the UART error routines is you don't reset the buffer and discard the sentence when you get a UART error. Keep in mind that with your implementation, any error anywhere means that you must discard the current sentence and wait for the next $ to begin receiving the next one. Accordingly, you must reset the buffer index and flags after any error to properly receive the new sentence. I've worked out a way to do that but don't want to overload you so didn't post it. Eventually, you'll have to incorporate something that does that.
Cheers!

 

Makes sense now, thanks.
Let us know what you find running the actual radio. Question: is there a time delay between sentences from the radio?
Error handling: one thing you are missing in the UART error routines is you don't reset the buffer and discard the sentence when you get a UART error. Keep in mind that with your implementation, any error anywhere means that you must discard the current sentence and wait for the next $ to begin receiving the next one. Accordingly, you must reset the buffer index and flags after any error to properly receive the new sentence. I've worked out a way to do that but don't want to overload you so didn't post it. Eventually, you'll have to incorporate something that does that.
Cheers!

Hi JT,
While testing the radios, I had some issues, including burning out a compass. I have spares, they're surface mount, but tiny, but should be repairable. (Another day)

The radios are working, but there's an issue with the DATASWITCH, which is a mystery, as I tried an old program, that we're replacing, and that one recieves REMOTE ok.

The radios are pretty quick as READing the GPS and 4431 are at approx 5/sec. I'll recheck this later as there may be WAITS in there.

Save your buffer resettig for later please, although there is a 'BUFFER clear' somewhere in some programs.

Thanks, C.

 

Can you post the old program that had the radio working? A look at it may be helpful.
Agreed that we can wait on more changes until you drill down into the radio error.

I asked the question about a delay between radio messages because if you change a channel when the data stream is active, that can generate UART errors. With the working channels at 5/sec, there is a good possibility that you are lucky enough to hit between messages most of the time. If there is little or no delay between the messages, the chances of jumping into the middle of a message increase and with that the probability of mis-handled errors increases too.

 

Save your buffer resettig for later please, although there is a 'BUFFER clear' somewhere in some programs.

Has the thought occurred to you that the buffer resetting might actually solve your problem? Putting it off until later might prevent you from finding an easy solution?