No Timeout When Using Serin With Qualifier

Goeytex

Senior Member
No timeout when using Serin with qualifier

Picaxe 14m2 / 20X2
Picaxe serin is connected to ASK RF receiver module data out.

Expected a timeout when qualifier "string" not detected within timeout period.

Serin will not time out as long as any data is seen on serin pin.

Code:
main:
do
serin [1000,timeout],B.1,T1200_4,("???"),b0
sertxd (#b0,cr,lf)
loop

timeout:
sertxd "Serial Timeout",cr,lf)
goto main
Please consider this a feature request so that when a qualifier is used, that the timeout is generated on the failure to receive the qualifier "string" within the timeout period rather than by counting bytes of random data.

Possible ?
 

westaust55

Moderator
I suspect that there is no problem with the timeout function in relation to the SERIN command. Try your program with a wired rather than radio connection as a test.

The timeout function occurs if the SERIN command has not received a start bit for a byte within the specified period after the SERIN command commences.
If there is RF noise, which is likely with a radio link, then there may be a change of state indicating a start bit and the following byte could be just noise rather than the qualifier.
If due to RF noise the byte does not match the qualifier, then the SERIN command resets back to the start of the qualifier and as something has been detected the timeout does not proceed.
 

lbenson

Senior Member
I think that Goeytex's analysis of the cause is the same as that of westaust55--random noise from an rf link.

What he's asking as a refinement of the timeout feature seems very reasonable to me--that when there are both qualifier and timeout in a SERIN command, the timeout should occur when the qualifier is not detected within the timeout period.

It seems to me unlikely that changing the current behavior would break any existing code, and on the face of it it is a desirable feature.
 

mrburnette

Senior Member
<...>
What he's asking as a refinement of the timeout feature seems very reasonable to me--that when there are both qualifier and timeout in a SERIN command, the timeout should occur when the qualifier is not detected within the timeout period.
<...>
To me, this would seem problematic when used to decode a "long string of serial information". Depending on when the PICAXE started to 'look' for the reference qualifier, the timeout could occur while still processing serial information... the fix, doubling any anticipated timeout to provide for worst-case. I tend to lean toward the current model, if a serial signal is being received, the timeout should remain reset at 0. However, I see no reason to not have both models available in new firmware.

- Ray
 

pmolsen

Senior Member
I second (third?) what Goeytex and lbenson have requested above. The timeout feature is of no benefit if a qualifier is used since a lockup can still occur. The only workaround would be to manually process the data searching for the "start" string instead of using a qualifier, which would be a huge step backwards.

I have Picaxe-18x code in place at present to test for a pin fluctuating (high/low) before I do a Serin (see below). Crude but effective. I was going to convert to 18M2+ and use a timeout so I could delete that code, but the new code would end up being just as long, searching for the start value instead if I want it to be lock-up-proof.

The way it is at present the Programming Editor might as well reject as invalid any Serin statement containing both a timeout and also a qualifier, since the result is NOT going to be what the majority of users would expect. (I was about to convert my code to use it, until I read this post.)

At the very least Manual 2 needs to spell out clearly the limitation. At present it says: "Timeout is an optional variables/constants which sets the timeout period in milliseconds."

And further down: "The timeout value, set in milliseconds, is the length of time the serin command will wait for a serial command to be detected."

What is a "serial command"??? I took it to mean "serial data containing the qualifier".


The command needs two timeouts to work properly, one for no serial data at all and a second for qualifier not found. One might typically set the first to say 2 seconds and the second to say 10 seconds.


Here is my current code. It will still hang if the serial data does not contain the qualifier, so I guess I should still convert to use the timeout and save a few precious lines of code:

' First check GPS input pin to determine if changing data is present.
' If we just do a serin and there is no data (eg. GPS dead or not present)
' then the program hangs forever.
' Pin is held low with a 10k resistor for when no GPS present.
w1 = 0
w2 = 0
for w0 = 1 to 500 ; check pin for about 1 second
if gpspin = 1 then
w1 = w1 + 1
else
w2 = w2 + 1
endif
pause 1
next
if w1 < 10 or w2 < 10 then gpsbad ; No gps serial data present

' Read GPS data and check if data valid.
' If GPS data-valid flag is "A" (good fix) then accept time and date.
' NB. At 8MHz you have to specify 2400bps on serin to read 4800bps data
' Serial data from GPS is True logic (0v=logic 0, 5v=logic 1) so specify T2400
' Read time hhmmss in b1-b6, valid or invalid flag in b7 and date ddmmyy in b8-b13

setfreq m8 ; run at 8MHz to allow reading serial data at 4800bps
serin gps,t2400,("$GPRMC,"),b1,b2,b3,b4,b5,b6,#w6,b7,#w6,#w6,b0,#w6,#w6,b0,#w6,#w6,#w6,#w6,b8,b9,b10,b11,b12,b13
setfreq m4

if b7 <> "A" then gpsnolock ; GPS not yet locked on to satellites

...
etc
 
Last edited:

noelnelson

New Member
I had the same problem with the timeout and qualifier, and found the answers offered in this thread to explain what I couldnt figure out. Thanks to all who contributed.
What I then did to get around the problem, is to use the timeout, and to include a dummy byte as the first byte sent in the serial data. On the receive side, the next line after the serin line, I simply do a 'if byte = dummy then goto...' line. If the byte does not equal the dummy then make another decision where to go. If it equals the dummy, ignore it as data, and continue with the next received data.

For more data security, this method could be expanded by multiplying all the sent data, (ignoring overflow) and sending the resulting byte (or Word) as a checksum. Then, receive all the data and the checksum, multiply all the data again and compare to the received checksum.


cheers
 

Maco33

New Member
Good idea, but how to do it? Have someone example a schema and the code? I wonder about sending dummy byte, HW and SW.
Pleas help me ;-)
M.
 

hippy

Technical Support
Staff member
Good idea, but how to do it? Have someone example a schema and the code? I wonder about sending dummy byte, HW and SW.
Pleas help me ;-)
M.
It is not possible to have a SERIN with qualifiers and timeout with any reliability when using dumb RF modules. Any noise present on the RF module output which passes to the serial input will cause the timeout counter to reset and the timeout not to occur.

It would be best to continue discussion on the related thread here -

http://www.picaxeforum.co.uk/showthread.php?29872-No-Timeout-When-Using-Serin-With-Qualifier
 
Top