I'll keep testing

Be sure to test the modified main with no call to setUARTchannel. Even though we don't update the channel number, that routine does some other things that the UART might object to. We need to know that before proceeding much further.

 

Be sure to test the modified main with no call to setUARTchannel. Even though we don't update the channel number, that routine does some other things that the UART might object to. We need to know that before proceeding much further.

Hi JT,
Here is CODE #234 with [setUARTchannel] commented out. The program is working again.
Here is a screen shot, of the SIM including VARIABLES showing [prs_done]
Changed lines include '++++++++++++
C.

 

Does it get more than 1 sentence?

 

Does it get more than 1 sentence?

Hi JT,
No, it reports UART not enabled.
C.

 

Hi JT,
No, it reports UART not enabled.
C.

Yeah.. my fault. The UART gets turned off after each sentence and stays off unless you call setUARTchannel. Go ahead and restore that gosub setUARTchannel to main. Sorry.

Are you testing on actual hardware or just the sim?
Is there a delay between sentences from the radio?

 

Yeah.. my fault. The UART gets turned off after each sentence and stays off unless you call setUARTchannel. Go ahead and restore that gosub setUARTchannel to main. Sorry.

Are you testing on actual hardware or just the sim?
Is there a delay between sentences from the radio?

Hi JT,
With the [setUARTchannel] there's no BUFFER filling as before, when I reported broken, see attached.

So far, I've only used the SIM, using selected sentences from attached:

EDIT: I notice on this image both [dataswitch_SX] are set as expected to REMOTE, but with the previous one that PARSED ok, it didn't switch them correctly.
C.

 

So you are back to running the exact code in #234 on the sim?
My understanding is that it ran awhile, got multiple sentences then quit. Is that correct?

 

So you are back to running the exact code in #234 on the sim?
My understanding is that it ran awhile, got multiple sentences then quit. Is that correct?

Hi JT,
Yes, it seemed to break the SIM, which wouldn't work again, unless I tried an earlier program. At the moment it's working, so perhaps a problem my end.
C.

 

OK. If it stops again, take a screenshot showing RCSTA and the Hardware UART Simulation Iterface window. I noticed in the sim that an OERR stopped the reception but did NOT set the OERR flag. The code won't work if that is true.
I'm going to look at it here..

 

OK. If it stops again, take a screenshot showing RCSTA and the Hardware UART Simulation Iterface window. I noticed in the sim that an OERR stopped the reception but did NOT set the OERR flag. The code won't work if that is true.
I'm going to look at it here..

Hi JT,
I tried a number of times, and it appears the timing that I click the UART to load it, is important. If I get it right, then it fills the BUFFER, if I let it run a while it it doesn't. If you have your SIM going watch [PIE]

EDIT: I've only been using SIM, live will only show if there is a sentence that has been PARSED and Sent to my computer terminal.
C.

 

Try this. There was a problem in the main loop, now fixed and tested. Sorry about that.
This is post #234 with the fixes.
It is still locked down to the REMOTE channel. To enable all, just uncomment

'Gosub next_channel TESTS: don't change channel, stay on REMOTE

in the main loop.
I finally figured out how to speed up the code sim so shot it with several ugly and good strings. It seems OK.
Keep in mind that I do not think the sim properly reports OERR. I'll check that again when I get a chance.
Sorry for the confusion.

 

Try this. There was a problem in the main loop, now fixed and tested. Sorry about that.
This is post #234 with the fixes.
It is still locked down to the REMOTE channel. To enable all, just uncomment

'Gosub next_channel TESTS: don't change channel, stay on REMOTE

in the main loop.
I finally figured out how to speed up the code sim so shot it with several ugly and good strings. It seems OK.
Keep in mind that I do not think the sim properly reports OERR. I'll check that again when I get a chance.
Sorry for the confusion.

Hi JT,
No need for apologies.
1x Channel noted.

I thought of a way to verify each sentence: Each of the 3x, are of different but fixed lengths between $ and W, so I assume if [buf(0) = $ and buf(X) = Y then.....] would work. What do you think? is it over the top?

Previously I reported, that OERR and perhaps FERR don't switch in the SIM, also there is a BAUDCON line in earlier programs that check for (I think) framing errors, and I don't think this worked either. The BAUDCON stalled the program when in SIM, but not in 'live'
Off to test your CODE.
C

 

Hi JT,
I had to add a few lines to clear [STRBUF] as the READout was being jumbled. The PARSED sentence now shows in the UART window.

The [prs_done] wasn't being swiched off.

In the SIM, it's almost working on 1x channnel, but of course the switch can't be switched.
'Live' the channel is set to [QEDEG] which works well, so of course the DATASWITCH is set wrongly.

main:  '/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

waitBuf:
    If buf_done = 1 Then
    buf_done = 0
    prs_fill = 1
    Gosub parse  'parse received sentence
    prs_fill = 0
    prs_done = 1
            'end of processing for now, update channel as necessary and loop
            'at this point, we just stay on RADIO channel
    'Gosub next_channel  TESTS: don't change channel, stay on REMOTE
    Gosub setUARTchannel  'start UART on channel(datasw), begins looking for sentence
    Endif
'+++++++++++++++++++++++++++++++++++++++++
If Len(strtim) <> 0 Then  'if string is zero length don't hserout........
    Hserout "T=", strtim, " N=", strlat, " W=", strlong, CrLf
    WaitMs 5  '????????????
Endif
If Len(qeideg) <> 0 Then
    Hserout "QEIDEG=  ", qeideg, CrLf  'QEIDEG=BASE 4431 Opto encoder
    WaitMs 5  '??????????
Endif

If Len(strremvolt) <> 0 Then
    Hserout "REMVOLT=", strremvolt, " REMALT=", strremalt, " REMDIST=", strremdist, CrLf
    WaitMs 5  '??????????
Endif

If prs_done = 1 Then
    strbuf = ""  'clears STRBUF
    prs_done = 0
Endif
'++++++++++++++++++++++++++++++++++++++++

Goto main

I'll see if I can fix it.

C

 

Hi,
I've fixed a DATSWITCH error. Now the switch switches to REMOTE, which shows in the Computer Terminal when LIVE.

Here is a Terminal view:
It shows the REMOTE after PARSING, but only updates each time the PCB is powered up. So the STRING isn't being changed at each INPUT.
C.

 

Post the code? Are you using the test code we've been working on? It should run on the hardware too, no?
In the last code I posted, you had some issues with 'parse' that needed fixing, I thought.

The [prs_done] wasn't being swiched off.

Pretty sure that we can reduce the number of flags as we go along. As I noted above, I am not a fan of lots of flags. As you noted, you forgot to clear prs_done and that was an issue. Consider this: you don't need a flag to know that the parse is DONE, you already know that because it returned from the parse subroutine so.. it's done.

I think a more useful set of flags would be a "new data" flag associated with each sentence. When you call and return from parse, you update AT MOST one set of data, that which is contained in the current sentence. The other data has not changed so needs no processing yes? So what you do after parse returns is inspect the series of "new_data" flags (only one will be set per sentence-parse) and you just process that new data. After you are done processing, you clear that flag indicating that the 'new data' has been processed and won't change until you get the next sentence containing that data. That way, you avoid a lot of redundant processing AND your code gets easier to maintain and modify. A real benefit of a 'new' flag for each decoded sentence is that you know that you actually processed that sentence. If it is possible (and I don't know what other sentences your system generates) to get another sentence like $DONT_CARE_ABOUT_THIS_ONE123456W, the parser will run to completion BUT the sentence won't be decoded and no useful data will change. So great!, we processed a sentence but we didn't get any new data to operate on. That's useful info.

I thought of a way to verify each sentence: Each of the 3x, are of different but fixed lengths between $ and W, so I assume if [buf(0) = $ and buf(X) = Y then.....] would work. What do you think? is it over the top?

No, I like as much verification as possible. In fact, checking the length of the loaded sentence is trivial since the way the buffer indexing works in the interrupt routine, when the sentence from $ -> W is complete and buf_full is set, the index variable, rxpsn, has the number of characters in the buffer from $ to W, inclusive. So after decoding which sentence you have, just compare rxpsn to the number of characters you expect for that message. Nice. So after you decode which sentence you have, compare rxspn with the appropriate known value and proceed only if correct. Note that rxpsn is valid until you call setUARTchannel again.

Onward!

 

Hi JT,

True, we can get rid of some of the Flags, perhaps later, as I'm used to them.
Here's the CODE:
Note +++++++++++++++++++

C.

 

I think you'll like this one.
Revs and fixes to parse, main loop control, "processed" sentence reporting. Added 'new data' flags as discussed above to manage processing of new data. Much discussion of all of this and more in the comments themselves.

I ran it up like this:
In IDE->Options, deselect Basic Program Tracking - it slows things down considerably.
No breakpoints
Open Hardware UART Simulation Interface
Start sim in Extreme Speed mode.
Wait until the UART window shows AT+C002 sent to the radio then use SendString to send any of the sentences you have in your 'Sentences.txt' file, good and bad, multiple sentences on same line etc.
You should see any UPDATED data reported ONCE in the UART window as sentences are parsed and decoded.
Note that it will process any known message even though the channels are not switching yet. It doesn't know the difference in the sim. Nice.
It should run on the real hardware if you enable channel switching..

Sorry about changes to your structure, it wasn't getting the job done and will be problematic when you put it back together with the full code. Some mods to the full code will be necessary but it will run better and be easier to work with.
We can add some testing of $-W length when you're comfortable.

Sent these one by one, including the ( ) comment!

$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?
$REMOTE,11,22,33,WXX,$REMOTE,44,55,66,WXX,$REMOTE,77,88,99,W XX
$QEIDEG,111,W,$QEIDEG,222,W, $QEIDEG,333,W, $QEIDEG,444,W (Note comma before $)
$GPRMC,111111,A,4807.038,N,01131.000,*6A?$QEIDEG,123$GPRMC,222222,A,4807.038,N,01122.000,W,W*6A?
$QEID,111,W$QEIDEG,333,W$REMOTE,22,22,22,W$REMOTE,77,8

and got this:


Note that it doesn't properly parse the last sentence because you don't properly qualify the $QEIDEG message in 'parse'. But it doesn't break the serial link as evidenced by the REMOTE sentence following.
Time to visit 'parse' and fix that. There are also some initialization issues that need to be fixed to make it better running on the hardware. We'll do that too.

Have fun for now!

 

I think you'll like this one.
Revs and fixes to parse, main loop control, "processed" sentence reporting. Added 'new data' flags as discussed above to manage processing of new data. Much discussion of all of this and more in the comments themselves.

I ran it up like this:
In IDE->Options, deselect Basic Program Tracking - it slows things down considerably.
No breakpoints
Open Hardware UART Simulation Interface
Start sim in Extreme Speed mode.
Wait until the UART window shows AT+C002 sent to the radio then use SendString to send any of the sentences you have in your 'Sentences.txt' file, good and bad, multiple sentences on same line etc.
You should see any UPDATED data reported ONCE in the UART window as sentences are parsed and decoded.
Note that it will process any known message even though the channels are not switching yet. It doesn't know the difference in the sim. Nice.
It should run on the real hardware if you enable channel switching..

Sorry about changes to your structure, it wasn't getting the job done and will be problematic when you put it back together with the full code. Some mods to the full code will be necessary but it will run better and be easier to work with.
We can add some testing of $-W length when you're comfortable.

Sent these one by one, including the ( ) comment!
and got this:
View attachment 211379

Note that it doesn't properly parse the last sentence because you don't properly qualify the $QEIDEG message in 'parse'. But it doesn't break the serial link as evidenced by the REMOTE sentence following.
Time to visit 'parse' and fix that. There are also some initialization issues that need to be fixed to make it better running on the hardware. We'll do that too.

Have fun for now!

Hi JT,
I haven't gone through your CODE yet, but I've tested it in SIM and LIVE.
Here's the reasult of LIVE:
$XXXXXX = TX from computer at 1/SEC
XXXXXX = RX to computer.
I'll have a look through then try all 3x channels. All channels will then be switched to TX at 5X/SEC.
Well done
C.

 

Hi TX,
Here's a LIVE test with 3x Channels TXing at 5X/SEC:
In the screen shot, you can see that sometimes the TIME is READ 2x/SEC, which is fast, and maybe after tuning it may be faster.
I was turning the QEDEG COMPASS knob while running, and you can see it is fine.
The REMOTE is also updating immediatelly.
I'm not sure what the misalignments are in the Terminal readings, but perhaps it needs a little time after HSEROUT, not sure. Sometimes it's fine, and may not affect the remote control.
I blank out my location for privacy, if I remember.

When testing in SIM, I was able to make it make mistakes, which may be caused by the [strbuf = ""] line being too late in the sequence. If possible can you move it to, after PARSE instead of before PARSE.

So good progress.
C.

 

3 channels - Nice!

I think the misalignment in the terminal readout is due to the radio being half-duplex i.e. can't transmit and receive at the same time. The HC-12 has some delay required to change directions which is detailed in the datasheet. It takes some time after the end of a message in one direction to be ready to send in the other direction. It's also possible that it is reporting the results of one of the other channels when the PC decides to send the $REMOTE message. That will also cause some losses. For diagnostics, it's just annoying. If you actually require 2 way comms in the final code, you'll have to figure out a way to coordinate the sending of $REMOTE messages with the receiving back from the PIC. If that's a real requirement, we can cogitate on that. Otherwise, I'd live with it.

When testing in SIM, I was able to make it make mistakes, which may be caused by the [strbuf = ""] line being too late in the sequence. If possible can you move it to, after PARSE instead of before PARSE.

strbuf = "" is necessary where it is. You need to start with a clean string before you start building a new one. The best place to init something is just before you use it. If you want to generate errors, add a piece of code to poke bad characters into the string after building it or set a breakpoint and modify the string manually.

n the screen shot, you can see that sometimes the TIME is READ 2x/SEC, which is fast, and maybe after tuning it may be faster.

Not sure what you mean. The code just reports what it receives. It might be faster because it isn't burdened with a bunch of blocking delays but if your GPS(?) is sending the time string at 2/sec then you are guaranteed to get time reports with the the same time value.

Carry on.