Add GPS/PARSE to 8xSERVO-MOTOR CODE in Oshonsoft

[camerart]

Hi,
Here is CODE for 18F4431 8xCH SERVO-MOTOR CODE using a shift register: https://www.electro-tech-online.com/threads/oshonsoft-interrupt-parse.159316/

Add GPS and PARSE CODE to the above CODE, in the same way.

Camerart

 

[camerart]

See my edit. Pre coffee maths.

Mike.

Hi M,
Is that like a 10 Gallon coffee mug?

EDIT: I think if an edit is too late than it may not get read!
C.

 

[jjw]

Can Oshonsoft do 64 bit integers?

Mike.

No, only 32bit unsigned integer.

 

[camerart]

No, only 32bit unsigned integer.

Hi M and J,
I've also just found out, no.

I'm not sure we need such an accurate calculation, as, I imagine it will work like this:

If $GNRMC,162254.00,A,3723.02837,N,12159.39853,W,0.820,188.36,110706,,,A*74
is compared with $GNRMC,162254.00,A,3723.02838,N,12159.39853,W,0.820,188.36,110706,,,A*74
and they're different, than move to the last location sent.
All this can be worked out later though, as there may be different 'best' ways to do it.
C

 

[sagor1]

Also remember that Oshonsoft uses regular 32 bit real numbers (modified IEEE754 standard), which are accurate to only 7 digits (about).
A number like 3723.02837 would get truncated to 3723.028 as a real number, losing accuracy.
When parsing the string, the value before the decimal point should be parsed as one number, the part after the decimal (or with the decimal) as another number.
Even if parsing like 37 degrees, 23.02837 minutes, the last digit may be +/- 1 digit from real value.

 

[camerart]

Also remember that Oshonsoft uses regular 32 bit real numbers (modified IEEE754 standard), which are accurate to only 7 digits (about).
A number like 3723.02837 would get truncated to 3723.028 as a real number, losing accuracy.
When parsing the string, the value before the decimal point should be parsed as one number, the part after the decimal (or with the decimal) as another number.
Even if parsing like 37 degrees, 23.02837 minutes, the last digit may be +/- 1 digit from real value.

Hi S,
'When parsing the string, the value before the decimal point should be parsed as one number, the part after the decimal (or with the decimal) as another number.'
So using this method, we could get good accuracy, is this correct?

If this is correct we will need to take care of stepping over the spot where the last digit before the decimal point clocks over.

Anyway, we'll all be repeating this when testing the machinery, so best save it till then.
C

 

[sagor1]

Hi S,
'When parsing the string, the value before the decimal point should be parsed as one number, the part after the decimal (or with the decimal) as another number.'
So using this method, we could get good accuracy, is this correct?

If this is correct we will need to take care of stepping over the spot where the last digit before the decimal point clocks over.

Anyway, we'll all be repeating this when testing the machinery, so best save it till then.
C

You could parse the "23.02837 minutes" into a real number, as in that example, just keep in mind that the last digit may not be that significant, and ignore any change of +/- 1 digit (ie: consider 7 to 8 as "no change"). I think that even 6 digits would be accurate enough. Not sure what happens if minutes is less than 10, does it insert a leading zero (I think it would)

 

[camerart]

You could parse the "23.02837 minutes" into a real number, as in that example, just keep in mind that the last digit may not be that significant, and ignore any change of +/- 1 digit (ie: consider 7 to 8 as "no change"). I think that even 6 digits would be accurate enough. Not sure what happens if minutes is less than 10, does it insert a leading zero (I think it would)

Hi S,
Looking forward to trying it 'live'
C

 

[Pommie]

You could parse the "23.02837 minutes" into a real number

What do you do about the degrees and the hemisphere? This is why I suggested converting to a 32 fractional value where zero and 0.99999999999 (0xffffffff) would be the range as 1 is the same as zero.

Not sure what happens if minutes is less than 10, does it insert a leading zero (I think it would)

I found a sentence with 5109.0262239 as a coord so the zero must accompany the 9 at 510° wouldn't make sense.

Mike.

 

[camerart]

What do you do about the degrees and the hemisphere? This is why I suggested converting to a 32 fractional value where zero and 0.99999999999 (0xffffffff) would be the range as 1 is the same as zero.

I found a sentence with 5109.0262239 as a coord so the zero must accompany the 9 at 510° wouldn't make sense.

Mike.

Hi M,

----------------------N------W
Mid UK------------ 52.623,-1.417
----------------------S------E
Mid Australia----, -24.287,135.242

Your system may work as well?
C

 

[camerart]

Hi,
Regarding the new PCB:
The 'shift register' has 2x DATA pins, I have connected them, as the tests, is this ok?
EDIT: There is a reset
C

 

[Pommie]

----------------------N------W
Mid UK------------ 52.623,-1.417

That confuses things, why isn't -1.417 W, 1.417 E.

The thing about GPS coordinates is the longitude is always great circles and split like segments of an orange but the latitude is only a great circle at the equator and gradually gets smaller until it's zero at the poles (bet that's caused a few bugs). Makes any calculations "interesting".

A difference of 1° E/W is a different length dependent on how far N/S you are.

Mike.

 

[Pommie]

The 'shift register' has 2x DATA pins, I have connected them, as the tests, is this ok?

Yup, as it needs to be or connect one of them to Vcc.

EDIT: There is a reset

That can be connected to a spare pin if you like, at the moment the shift register is cleared in the for loop that sets up the servo times.

LATC.0=0            'ensure data is low
LATC.2=0            'and clock
For i = 0 to 7
  LATC.2=1                  'send positive clock edge
  servoPos(i)=i*250+2000    '1ms(2000) to 1.875(1 7/8ths - 3750)ms in 1/8th mS steps
  LATC.2=0                  'send negative edge
Next i

This should execute very fast and clear all outputs of the shift register (hopefully before the servos have completed there power on setup time). The reset pin should be tied high in this case. An alternative is to use a capacitor resistor reset circuit.

Mike.

 

[camerart]

That confuses things, why isn't -1.417 W, 1.417 E.

The thing about GPS coordinates is the longitude is always great circles and split like segments of an orange but the latitude is only a great circle at the equator and gradually gets smaller until it's zero at the poles (bet that's caused a few bugs). Makes any calculations "interesting".

A difference of 1° E/W is a different length dependent on how far N/S you are.

Mike.

Hi M,

If you think of hemispheres:
North of the equator is '+' so no sign
South of the equator is '-' so has '-' sign

East of Greenwich and West of the Date line is '+' so no sign
West of Greenwhich and East of the Date line is '-' So has a '-' sign.

With the suggested compare two readings, as #23, there is no need for any calculation.

I'm happy to simply test with $ to W, so we can get some results, without too much thought.

I'm sure things will arise, that I hadn't imagined, that we can tackle first, then work through each by importance.
C

 

[camerart]

Yup, as it needs to be or connect one of them to Vcc.

That can be connected to a spare pin if you like, at the moment the shift register is cleared in the for loop that sets up the servo times.

LATC.0=0            'ensure data is low
LATC.2=0            'and clock
For i = 0 to 7
  LATC.2=1                  'send positive clock edge
  servoPos(i)=i*250+2000    '1ms(2000) to 1.875(1 7/8ths - 3750)ms in 1/8th mS steps
  LATC.2=0                  'send negative edge
Next i

This should execute very fast and clear all outputs of the shift register (hopefully before the servos have completed there power on setup time). The reset pin should be tied high in this case. An alternative is to use a capacitor resistor reset circuit.

Mike.

Hi M,
The above is not clear.
I would like the fewest tracks I need to add, as long as it works.

At the moment, it is working. The reset is tied high.
The 2x DATA pins are tied together and go to RC0
The CLK goes to RC2.
If this is ok, then good.
C

 

[Pommie]

North of the equator is '+' so no sign
South of the equator is '-' so has '-' sign

East of Greenwich and West of the Date line is '+' so no sign
West of Greenwhich and East of the Date line is '-' So has a '-' sign.

I realize this and question why have the hemisphere at all? We don't need E and S at all!!!

I thought the reason for having the hemisphere was so no sign was involved and no confusion can arise.
With ± we don't know if + is East or West.

The complications of doing calculations on a globe just increased.

Mike.

 

[Pommie]

Hi M,
The above is not clear.
I would like the fewest tracks I need to add, as long as it works.

At the moment, it is working. The reset is tied high.
The 2x DATA pins are tied together and go to RC0
The CLK goes to RC2.
If this is ok, then good.
C

Yup, all good.

BTW, why does the number of tracks matter?

Mike.

 

[camerart]

Yup, all good.

BTW, why does the number of tracks matter?

Mike.

Hi M,
I have to weave them on the new PCB, so less weaving,=good.
C

 

[camerart]

Hi,
Now that the GPS is going to be on this 4431 PIC, I've removed the switch that previously switched it, and added the 74HC164 Chip, on the new PCB (PCB9)
This need double checking over a few days, before sending the order.

So next is adding the SERVO CODE into the GPS CODE. This may take a while.
C

 

[Pommie]

The ISR controls the servos and receives a sentence from the GPS. The background program (at the moment) is just moving the servos to demonstrate that it's all working. The background program (in the while loop) can be replaced by the parsing code and then move the servos to where they need to be. Once the sentence is parsed the isDone bit should be cleared so it (the ISR) can receive another sentence.

So, it seems to me that next is adding the parse code to the servo code.

Mike.

 

[camerart]

The ISR controls the servos and receives a sentence from the GPS. The background program (at the moment) is just moving the servos to demonstrate that it's all working. The background program (in the while loop) can be replaced by the parsing code and then move the servos to where they need to be. Once the sentence is parsed the isDone bit should be cleared so it (the ISR) can receive another sentence.

So, it seems to me that next is adding the parse code to the servo code.

Mike.

Hi M,
To clarify, does this

So, it seems to me that next is adding the parse code to the servo code.

mean SERVO parse CODE?
If so, then, if I understand, this will be ok for now, until the SPI section is working.
-------------------------------------------------
ServoPos(0) =XXXX 'Add test numbers
ServoPos(1) =XXXX
ServoPos(2) =XXXX
ServoPos(3) =XXXX
ServoPos(4) =XXXX
ServoPos(5) =XXXX
ServoPos(6) =XXXX
ServoPos(7) =XXXX
---------------------------------------------------
C