Busy today but Hserout can transmit with the UART ‘off’. We only shut down the RX. Maybe the new parse tests are rejecting corrupt Remote messages?

Agreed on the need for a guard timer on the messages.

Hi TX,
Ok.
I'm just looking through #277, with the SIM.

C.

 

In #277 I moved the calls to next_channel and setUARTchannel to right after parse returns. You might want to move those back to after you type out the results I.e just before the goto main_loop. Forgot about your half-duplex radio link

 

In #277 I moved the calls to next_channel and setUARTchannel to right after parse returns. You might want to move those back to after you type out the results I.e just before the goto main_loop. Forgot about your half-duplex radio link

Hi JT,
Checking will take me a bit of time to check your latest CODE, but I ran it LIVE and it didn't work properly, perhaps this is what you are saying?

As your busy, just a quick note: I see that you marked the time as GMT, but actually it's British summer time here, so BST is correct. Do you mess with the time over there?

C.

 

Checking will take me a bit of time to check your latest CODE, but I ran it LIVE and it didn't work properly, perhaps this is what you are saying?

Another old programmer's axiom is 'If you futz with something long enough you will surely break it.'
I'll try to check it here.
Are you sure the messages are the same exact length as in your 'sentences.txt' file?

Re:GMT, I wanted to keep the timestamps the same as yours. I'll use BST then.

 

Another old programmer's axiom is 'If you futz with something long enough you will surely break it.'
I'll try to check it here.
Are you sure the messages are the same exact length as in your 'sentences.txt' file?

Re:GMT, I wanted to keep the timestamps the same as yours. I'll use BST then.

Hi JT,
Perhaps it's best I try agin tomorrow, in case I made some mistake, before you try to correct it. Just in case.
Cheers, C.

 

#277 started with the GPS channel so if you were having problems there, it would hang. We need those guard timers. Next rev.
This starts with REMOTE again. It also reports if you get an error from parsing any string.
I moved the 'READY' output to AFTER you init the HC-12. I'm guessing if the PC comms is via the radio it should be inited before trying to write?
See other notes.

Question: are you using any of the PWMs?

 

#277 started with the GPS channel so if you were having problems there, it would hang. We need those guard timers. Next rev.
This starts with REMOTE again. It also reports if you get an error from parsing any string.
I moved the 'READY' output to AFTER you init the HC-12. I'm guessing if the PC comms is via the radio it should be inited before trying to write?
See other notes.

Question: are you using any of the PWMs?

Hi JT,
I haven't looked at the program and notes yet, only been mainly testing in SIM, then a quick LIVE that showed the same results.

In SIM, all seems to be working, apart from the $GNRMC sentences.
Using these as a test:
-------------------------------------------------------------------
$GNRMC,123456.00,A,1234.76019,N,01234.93717,W,0.301,,150620,,,A*7E
$GNRMC,123456.80,A,1234.77326,N,12345.94201,W,0.213,,140620,,,D*70
$GNRMC,111111.11,A,1111.038,N,11111.00000,W,W*6A?
$GNRMC,222222.22,A,2222.038,N,22222.00000,W,W*6A?
$GNRMC,333333.33,A,3333.038,N,33333.00000,W,W*6A?
$GNRMC,444444.44,A,4444.038,N,44444.00000,W,W*6A?
$GNRMC,085713.40,A,5555.77777,N,00222.99999,W,0.426,,080720,,,A*76
Quiet! Artist at work
--------------------------------------------------------------------------------------
The red ones didn't work, including the LIVE test where the sentences are the same as the red ones. All reported ERROR.
The green ones did work.
The error seemed to happen after the W while PARSEing, so I don't think length is a problem.
Perhaps you can see where it lies.
I'll keep looking.
C.

 

The red ones are a different length than the green ones. The latest version expects the length between $ and the first W to be fixed for each type of sentence. You can change the length spec by changing the Const values in parse.
If the red ones are correct, change Const ixGNRMC_X = 42 to 44.

 

Hi JT,
I think I've found the error
This is the correct format but doesn't work:
$GNRMC,123456.80,A,1234.77326,N,12345.94201,W,0.213,,140620,,,D*70
This is un correct, but does work:
$GNRMC,111111.11,A,1111.038,N,11111.00000,W,W*6A?

Note the difference is:
$GNRMC,123456.80,A,1234.77326,N,12345.94201,W,0.213,,140620,,,D*70
So the PARSE needs lengthening by 2x digits.

I'll look at the CODE, but I'm reluctant to change it.

EDIT: In reply to #288. If I use the long ones, which are as the GPS Sentences are, and if the 2x digits are removed, then they work, so I assume that part of the PARSE need lengthening at that point.

EDIT EDIT: The PWMs will be used in the REMOTE for controlling Motors etc
C

 

See edited #288
change Const ixGNRMC_X = 42 to Const ixGNRMC_X = 44.

 

H

The red ones are a different length than the green ones. The latest version expects the length between $ and the first W to be fixed for each type of sentence. You can change the length spec by changing the Const values in parse.
If the red ones are correct, change Const ixGNRMC_X = 42 to 44.

Hi JT,
That appears to have corrected it
Here is a LIVE view:

I notice errors with QEIDEG. It looks like it reports an error if there aren't 3xdigits. I'll check.
C.

 

I should remind you that the channel number in the Parse Fail message is only valid when running live. It just reports the value of datasw when parse was called. In the sim, you can paste and process any sentence regardless of the value of datasw so ignore the channel number when in the sim.

 

See edited #288
change Const ixGNRMC_X = 42 to Const ixGNRMC_X = 44.

John,
This only works because there happens to be a W in the 44th character of the “green” sentences. Is this guaranteed? There isn’t two Ws in the red sentences...

 

John,
This only works because there happens to be a W in the 44th character of the “green” sentences. Is this guaranteed? There isn’t two Ws in the red sentences...

As understand it, the first W is used as the terminator in all of the real sentences. The others were test sentences that were accepted until I put the length qualification on them. I am assuming that the format for each is fixed.

 

I should remind you that the channel number in the Parse Fail message is only valid when running live. It just reports the value of datasw when parse was called. In the sim, you can paste and process any sentence regardless of the value of datasw so ignore the channel number when in the sim.

Hi JT,
Yes, I've been doing that.
C

 

John,
This only works because there happens to be a W in the 44th character of the “green” sentences. Is this guaranteed? There isn’t two Ws in the red sentences...

Hi D,
The WWs may have been a test, but there's only 1x W in the 'real' messages for WEST.

EDIT: I see that JT, also replied with the same answer.
C

 

Hi D,
The WWs may have been a test, but there's only 1x W in the 'real' messages for WEST.

EDIT: I see that JT, also replied with the same answer.
C

Good! Thanks for the explanation. I didn’t understand that the messages were fixed length.

 

Hi JT,
It seems that the QEIDEG won't accept numbers between 0 to 99, so gives an error. 3x digits seems fine.

As long as there's a signal, the GPS is working ok.

The REMOTE errors a little, missing sometimes 1 in 3 messages. Remembering that I'm TXing them to the PCB.
C.

 

See edited #288
change Const ixGNRMC_X = 42 to Const ixGNRMC_X = 44.

Hi JT,
I hope you mean [ixGNRMC_W] not [ixGNRMC_X]
C.

 

Hi JT,
I hope you mean [ixGNRMC_W] not [ixGNRMC_X]
C.

Yep, typo. Sorry.

Hi JT,
It seems that the QEIDEG won't accept numbers between 0 to 99, so gives an error. 3x digits seems fine.

That's because if you are not padding the value to 3 digits e.g. 099, the length of the string will vary with the number of degrees and the length test will fail. Even without the length test, the parsing of the digits will fail since both your original MidStr and my replacement expect a fixed number of digits in a known place in the string. If QEIDEG works that way, we have to change how the received sentence is parsed.

As long as there's a signal, the GPS is working ok.

Correct. We still need to add a timeout for missing messages to avoid it hanging up. It's on the list.

The REMOTE errors a little, missing sometimes 1 in 3 messages. Remembering that I'm TXing them to the PCB.

I expect that is because the HC-12 is is half-duplex. You are sending back the result of the previous sentence to the PC when the REMOTE message is sent. It won't get through until the transmission to the PC is over.