hi,
The get_mess is extinct.
Copy and over Paste that Low Int with this code clip.
Rerun the test
E
BTW: for this test I have disabled timer1 int, re-enable ans see the print out
EDIT:
Added the hser print
View attachment 157414

Hi E,
The STR1 STRING isn't clearing, so it seems it's corrupting the next sentence.
TMR1 enabled.
C.

 

hi,
What do you expect to happen if Tmr1 High interrupt occurs during the time that the USART Low interrupt is servicing the RXD serial input.?
I did point out the other day this will cause a problem, because the remote USART will not stop sending while Tmr1 is servicing the Servo's every 20mSec.

There is no handshaking on the USART input.
E
Refer:
Posts #89, #103

 

hi,
What do you expect to happen if Tmr1 High interrupt occurs during the time that the USART Low interrupt is servicing the RXD serial input.?
I did point out the other day this will cause a problem, because the remote USART will not stop sending while Tmr1 is servicing the Servo's every 20mSec.

There is no handshaking on the USART input.
E
Refer:
Posts #89, #103

Hi E,
This is the REMOTE.

How do RC RECEIVERS get round this? I got the impression that the TMR1 INTERRUPTS for a fraction of a second then allows the USART to run.

You showed some CODE at #137, I think it is for converting the $BASE numbers to decimal numbers? How does it fit in the program?

C.

 

Hi E,

i hope this is correct! If you start the SIM, and after 14000uS ish, SEND NMEA STRING. The NMEA sentence is moving, and the ON PIN changes from RB0 to RB1 while the NMEA sentence keep moving. Is this what we want?
C.

 

hi,
The problem is the Remote [ by remote I mean the USART thats on the sending end] does not know when the receiving PIC's USART is free to receive the complete GPS and Base messages.
The two ends are working asynchronously.

Consider the timing, the baud rate is 9600, thats approx 960 chars/sec [ say 1000/sec ,,, 1mSec/Char].
So a GPS msg is 80 chars long, thats 80mSec every 1Sec, the Base msg is 25 chars long thats 25mSec every 1Sec.
As I understand your servo's [???] Tmr1 is servicing them at a 20mSec interval.

As it is designed at the moment there are going to be timing conflicts.

E

changes from RB0 to RB1 while the NMEA sentence keep moving. Is this what we want?

The problem the sim will wait, but the real USART hardware will not.

 

hi,
The problem is the Remote [ by remote I mean the USART thats on the sending end] does not know when the receiving PIC's USART is free to receive the complete GPS and Base messages.
The two ends are working asynchronously.

Consider the timing, the baud rate is 9600, thats approx 960 chars/sec [ say 1000/sec ,,, 1mSec/Char].
So a GPS msg is 80 chars long, thats 80mSec every 1Sec, the Base msg is 25 chars long thats 25mSec every 1Sec.
As I understand your servo's [???] Tmr1 is servicing them at a 20mSec interval.

As it is designed at the moment there are going to be timing conflicts.

E

The problem the sim will wait, but the real USART hardware will not.

With the 32MHz clock the servo interrupt takes less than 10us / each 1-2 ms servo on time.
Maybe ~ 5us, I did not look it exactly.
It can be shortened a little by using select case or if then else statements in the servo interrupt.
Then there is at least 8ms free time (with 6 servos)
Is that too slow?

 

hi jjw,
I think it would help us if we new the required update rates of the GPS and Base data.
As I understand its a R/C model aircraft thats being controlled, so how often the different servo's need updating, I do not know.?

Also he should consider what happens to the aircraft, if the radio signal is lost or the received data is corrupted.

E

 

I thought it is a quatrocopter?
Maybe it has been explained before, but I don't know why to transmit the servo data with serial data RF link, when there are ready made R/C transmitters.

 

hi jjw,
My understanding, from the original project, started in 2014, is that the R/C will transmit back its GPS position data to a Base station.
The Base unit will have a Yagi antenna and will auto track the remote R/C aircraft.
The project has grown in complexity over the past few years.

I would say it is time for 'camerart' to refresh/update the projects written specification.

I am keen to help, but we seem to be going around in ever decreasing circles., like the proverbial oozlum bird....

Eric

 

Hi E and J,
Let's see if we can stop our circles decreasing

I have tried to clarify what this project is trying to achieve in #1

This section does appear similar to a ready made transmitter, but it is for checking the BASE TRANSMITTER POTS and the REMOTE RECEIVER SERVOS only. Once working (If it's possible) then the main project can move forward. I am using SERVOS as a substitute for motor drives, but it's only for testing.

In #116 is the type of TRANSCEIVER radio I was using before this project was conceived which are capable of controlling 8x SERVOs while receiving telemetry. (Atmega chip)

I use MODE 2 See attached:

I make Tricopters! Quadcopters and Helicopters have similarities, but are controlled in different ways. It may be best to think of HELICOPTER until the differences manifest themselves.

Was it really 2014 when I started the TRACKER project. Indeed the REMOTE does send DATA back to the TRACKER. This is a different project, but when the BASE sends the location DATA to the REMOTE, the TRACKER could receive it as before, and aim toward the REMOTE. (Must finish it)

The GPS sends DATA at 1/sec, but can work at 5/sec. The BASE sends DATA each time the MAIN LOOPs.

This is a very ambitious project for me especially. I'm actually quite surprised that it has gotten this far, which only can happen with all of your help, so thanks.

I hope I've cleared all of the questions, let me know if not.
C.

 

hi C,
Do you have a circuit diagram showing how all these modules are interconnected.?
E

 

hi C,
Do you have a circuit diagram showing how all these modules are interconnected.?
E

Hi E,
I haven't looked at it for a long time, but here it is:
I notice it says TX. I am hoping that the TX and Rx can be the same, but with different programs.
C.

 

hi C,
I will look at the circuit.
One question do you really need a 5110 LCD on the craft.??
With regards to the Timing conflicts I would consider this change to the hardware.
Say a 18F2520 running the Tmr1 20mSec Int for servicing the Servos.
The 18F2520 would be connected to the 18F4520 via I2C and a Ready line..

The 18F4520 would be free to receive incoming radio RXD data for GPS and Base, it would also do all the required data verification, conversions and maths.
When the 18F2520 Ready line is enabled, during the 8mSec delay period, the high speed I2C would transfer its data to the 18F2520.

If you want to consider this method let me know and I will expand the description.

E

 

hi C,
I will look at the circuit.
One question do you really need a 5110 LCD on the craft.??
With regards to the Timing conflicts I would consider this change to the hardware.
Say a 18F2520 running the Tmr1 20mSec Int for servicing the Servos.
The 18F2520 would be connected to the 18F4520 via I2C and a Ready line..

The 18F4520 would be free to receive incoming radio RXD data for GPS and Base, it would also do all the required data verification, conversions and maths.
When the 18F2520 Ready line is enabled, during the 8mSec delay period, the high speed I2C would transfer its data to the 18F2520.

If you want to consider this method let me know and I will expand the description.

E

Hi E,
5110: I am trying to make both PCBs the same. The 5110 can be plugable so able to be disconnected and bypassed in the program.

I2C: Is there any reason to choose I2C over SPI? I've read that SPI is faster and more reliable. I can re-check. There are already 3x SPI modules on the PCBs.

TMR1: Will you double check, that for 4xCH, TMR1 isn't actually 5x times 'say' 2000INT, 2000INT, 2000INT, 2000INT, 16000INT which add up to 20,000uS where each INT takes a few uS with all the rest of the time (Poss 19,000uS) available for the program and UARTs? That's how I see it, but happy to be corrected.

I'm happy to use this method, if necessary

C.

 

hi.
SPI or I2C I am just trying to minimise the transfer time of the servo Tmr1 data, use the one you prefer.

Are you suggesting using the short free uSec frame load periods, were the Tmr1 Int can occur at +/-1mSec intervals, to do a transfer when you have a known free 8mSec.?

E

 

Hi E,
5110: I am trying to make both PCBs the same. The 5110 can be plugable so able to be disconnected and bypassed in the program.

I2C: Is there any reason to choose I2C over SPI? I've read that SPI is faster and more reliable. I can re-check. There are already 3x SPI modules on the PCBs.

TMR1: Will you double check, that for 4xCH, TMR1 isn't actually 5x times 'say' 2000INT, 2000INT, 2000INT, 2000INT, 16000INT which add up to 20,000uS where each INT takes a few uS with all the rest of the time (Poss 19,000uS) available for the program and UARTs? That's how I see it, but happy to be corrected.

I'm happy to use this method, if necessary

C.

Yes, 4 channels means 5 interrupts during 20ms period, each taking about 10us ( maybe less, I will check it)
If Rx-interrupt is short, for example just saving the character and incrementing the buffer index, there should not be timing conflicts?

 

hi.
SPI or I2C I am just trying to minimise the transfer time of the servo Tmr1 data, use the one you prefer.

Are you suggesting using the short free uSec frame load periods, were the Tmr1 Int can occur at +/-1mSec intervals, to do a transfer when you have a known free 8mSec.?

E

Ok, SPI for now.

How I see the TMR1 working is: The program is running, the TMR is also running. The INTERRUPTs only use the time taken by the RED lines and the program can use all of the time taken by the GREEN lines.

EDIT: I've just seen J's reply, which seems to concur. Meaning the RED lines/TMR1 may use only 50uS total.
C.

 

hi C,
I do not see the logic in chopping up the transfer into uSec events, when there is always a predictable ~8mSec free every Tmr1 frame.??

BTW: I have sent you a PM
E

 

Hi,
True there is a predictable 8mS TMR1 frame, plus a GPS sentence input every 1sec, plus a DATA sentence every LOOP of the Transmitter program. I'm not sure how these timings interact with one another, especially the INTERRUPT chopping of the incoming UART sentences.

There is a switch (un tested) on the PCBs to separate incoming sentences, which will be able to select which sentence to READ, but I'm not sure how to select between them yet?

I think I should try to implement the CODE at #137 and see what happens in a live test.

C.

 

Hi,
I am trying to blend the CODe from #137 into the program and remove 'get_mess'.

There appears to be two ways of parsing out the usable DATA from the NMEA and BASE sentences. CASE or PROC. Here are the two types (I think) :
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'This subr extracts the main values from the GPS string, into named value messages
'also converts the string to a named numeric value, for maths
'NOTE: hserouts for demo test only
get_val:
Select Case csv 'COMMA POSITION VALUES
Case 1

Case 2
strtim = LeftStr(msg1, 2) + ":" + MidStr(msg1, 3, 2) + ":" + MidStr(msg1, 5, 2)
Case 3
strlat = LeftStr(msg1, 10)
sinlat = StrValS(strlat)
Case 5
strlong = RightStr(msg1, 11)
sinlong = StrValS(strlong)
Case 12
Case Else
EndSelect
msg1 = ""
Return
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'parse msg string into 4, Tmr1 count Up values
Proc strs2hex2(arg1 As String)

st0 = MidStr(arg1, 1, 4)
st1 = MidStr(arg1, 6, 4)
st2 = MidStr(arg1, 11, 4)
st3 = MidStr(arg1, 16, 4)

wt0 = StrValW(st0)
wt1 = StrValW(st1)
wt2 = StrValW(st2)
wt3 = StrValW(st3)

wt0 = 65535 - wt0 ''' wt0= NOT wt0 is the same as 65535 -wt0
wt1 = 65535 - wt1
wt2 = 65535 - wt2
wt3 = 65535 - wt3

'the wt is the TMR1 load value
Hserout #wt0, ",", #wt1, ",", #wt2, ",", #wt3, CrLf
End Proc
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Which one is the best method, or is there a reason for two types?
C