Hi, UPDATE
A new PCB. Both BASE and REMOTE PCBs are the same, but slightly different connections. First the REMOTE.
The 18F4431 now READS the Compass.
I'm now trying to figure out how the 18LF4620 program READs messages from the 4431, in a similar way to the INCREMENTAL ENCODER on the BASE PCB.
Here's the Programs, SCH and PCB:
EDIT: Programs updated
C

 

Hi,
I'm a bit stuck with the 18LF4620 program!
The 4431 is TXing the Compass READing [$COMPDEG,XXX.XX,W] ok and it is arriving at the DATASWITCH on the 4620.

When I run the 4620 program in SIM, there appears to be something wrong with the PARSEing. I can see the DATA in the 'BUF', but then nothing happens.
Hopefully, I copied and pasted all of the sections ok.
I don't fully understand this area of the program, and quite how it works!
EDIT: Being stuck is my lack of programming skills, but I have just looked in this thread for where the bit I'm stuck on was introduced, and found long explanations from JT explaining everything. Here it is for any one else interested. Hopefully, I should be able to pick through and find my problem??
C

 

Hi, [[ REMOTE]]
I've swapped the Compass from 4620 to 4431 PIC, as a time saver.
It is now working, Here's the result in Terminal view.
C

 

Hi, [[ REMOTE]]
I've swapped the Compass from 4620 to 4431 PIC, as a time saver.
It is now working, Here's the result in Terminal view.

I think the BASE and REMOTE maybe working

When working on either BASE or REMOTE, I use a computer Terminal to SEND Macros to simulated messages from the other PCB.
Next see if they can 'talk' to each other without my messages.
C.

 

Could you rotate the compass to check if the angles are correct.

 

Could you rotate the compass to check if the angles are correct.

Hi J,
The compass used was calibrated using Magmaster last week and using the averaging CODE, so it was smooth.
When I tested the angles, it was completelly wrong, so I tried different Compass modules, till one gave a 360° output, which was about right for now. (This measn the BIAS values weren't acting properly) (It appears to be the Z axis that is causing problems)

Once I've got the BASE and REMOTE to talk to each other, I'll have a closer look at how the compasses work, and post findings on a separate thread.
C.

 

Hi,
With 4x programs over 2x PCBs, I'm finding it a bit too much, so I've decided to make the BASE PCB5 to match the one being worked on 'REMOTE PCB5'
C.

 

Hi,
The 18F4431 is now READing the Compass.
What would cause this effect on the HSEROUT?
______________________________________________________
$ÃOMPDEÇ 340.57×
$COMPDEG 340.57W
$COMPDEG 340.57W
$ÃOÍÐÄEÇ 340.57W
$ÃÏMPÄEÇ 340.57W
$COMPDÅG 340.49×
$COMPÄÅG 318.47×
$ÃOÍPDEG 218.24W
$ÃÏMPÄEG 17.91W
$COMPDEÇ 144.03W
__________________________________________________________
C.

 

Do you mean the wrong characters or changing degrees or both?
Are the messages from the radio link?

 

Do you mean the wrong characters or changing degrees or both?
Are the messages from the radio link?

Hi J,
Wrong characters. I moved the compass round to get the different READings.
C

 

hi C,
Many of those 'odd' characters are due the data string getting Bit #7 in the Byte incorrectly set.

Check for Timing problems
E
Look here, compare the Byte , Bit pattern
https://theasciicode.com.ar/

 

hi C,
Many of those 'odd' characters are due the data string getting Bit #7 in the Byte incorrectly set.

Check for Timing problems
E
Look here, compare the Byte , Bit pattern
https://theasciicode.com.ar/

Hi E,
OK, will do, thanks.
Note: This is a second PCB which is the same as the first, with the same program etc. But it's worth a double check.
C.

 

hi C,
Many of those 'odd' characters are due the data string getting Bit #7 in the Byte incorrectly set.

Check for Timing problems
E
Look here, compare the Byte , Bit pattern
https://theasciicode.com.ar/

Might be for those Eric, but it does not explain the "W" and "x". Both of those have the high bit clear, but totally different bit patterns. I suspect either "noise" of some sort or an overflow/framing error. Strange part is that this is at the end of the string only, it seems. And, it is consistent between the "W" and the "x".
If this is being printed by Hersout, then perhaps the baud rate generator is not exactly on the right baud rate.

 

Hi E, J and S,
Working with 2xPCBs with 2x programs and a 2x channel oscilloscope, is like an Octopus typing!

It appears that I loaded the problem PCB with a SIM timed program and the 'good' one with the 'run' time program, once reprogrammed correctly, it worked ok. So it was a timing issue, embarrasingly!
__________________________________________________
$COMPDEG 218.02W
$COMPDEG 217.75W
$COMPDEG 212.10W
$COMPDEG 225.99W
$COMPDEG 217.31W
$COMPDEG 216.03W
$COMPDEG 217.73W
$COMPDEG 217.75W
$COMPDEG 222.25W
$COMPDEG 220.55W
____________________________________________________________
The compasses aren't workng correctly, but I'll leave that for now, as it's complicated.

Next I will connect all of the other peripherals to PCB2, and re-test, then report back.

Thanks all for the diagnosis.
C.

 

Hi,
Spoke too soon!
The hieroglyphs in #788 are back, it seems to be an intermittent problem.

Could it be that the 2 PICs aren't 'beating' at the same speed? 1x has a Crystal and the other uses internal osc.
Can the crystal on 18LF4462 also time the 18F4431 PIC? If so can I add wires/tracks between them.
I can add a crystal to 4431 if necessary.

Note for each peripheral, I make a connecting lead, made fro computer signal cable, and I always have mix ups with SDI/SDO or MISO/MOSI. I'll make a new one for the faulty PIC.
C

 

From Microchip forum:

PIC18F4431 is a very old PIC18 which has a low accuracy internal oscillator (+/-15%...) see table 26-6 in datasheet.
So, if you need to use the UART, you must use an external XTAL because a +/-2% max frequency accuracy is needed for UART operation...

 

Agree with JJW. Read section 3.6.1 of the 18F4431 datasheet. It suggests ways to correct the oscillator via OSCTUNE based on UART errors.
Final suggestion, when working with UARTs, always use a crystal if possible, especially if working at higher speeds. Other option is to put in a short pause between characters (1ms). That allows the UART to re-sync on the new start bit for each byte. It does slow down the entire effective baud rate, but eliminates a lot of baud rate errors

 

Agree with JJW. Read section 3.6.1 of the 18F4431 datasheet. It suggests ways to correct the oscillator via OSCTUNE based on UART errors.
Final suggestion, when working with UARTs, always use a crystal if possible, especially if working at higher speeds. Other option is to put in a short pause between characters (1ms). That allows the UART to re-sync on the new start bit for each byte. It does slow down the entire effective baud rate, but eliminates a lot of baud rate errors

Hi S and J,
That all figures! Previously, before I used UART, I tried the 4431 as SLAVE from the MASTER PIC, and coudn't get it to work.

1x PCB works, so may have a slightly different timing.

I'll add a Crystal.

A previous question, where I doubt the answer being yes! Can 2x PICs run off 1x Crystal?
Thanks, C.

 

A previous question, where I doubt the answer being yes! Can 2x PICs run off 1x Crystal?

No, but you could get a standalone crystal oscillator and run both processors off that.

 

No, but you could get a standalone crystal oscillator and run both processors off that.

Hi JP,
I guessed, and you answered NO, I've just tried it, and of course it stalls the first Crystal.
Then I added a Crystal and as I've only just 'finished' this PCB, I stuck it on top of the 4431, but I haven't got it to 'fire up' yet, perhaps it's inducing into the PIC, or some other program setting is wrong.
Thanks,
C.