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

Senior 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
 

matchbox

Senior Member
Has this issue been fix with newer firmware?
If not. Why is that?

Due to the fact that both the Timeout and Qualifier are in the same serin command.
It would be logical to say, that if the Qualifier isn't seen in the timeout period, then move to the next line of code.
Why is it being held up with other data? We're only looking for data with that specific qualifier.
 

hippy

Senior Member
Has this issue been fix with newer firmware?
If not. Why is that?
The main issue is the effort required to rewrite and test the firmware plus having to find the space within the firmware to implement the change which would be required for all PICAXE variants.

The firmware is highly optimised for handling a serial input bit stream and changing the way timeouts are handled would mean duplicating a lot of code to handle both with and without qualifiers.

As noted by 'mrburnette' and others note above; there are also edge cases which need to be handled such as having seen the qualifiers but not any subsequent data. This makes it difficult to find a solution to the problem which has consistent and desired behaviour.

Given it is an issue which only affects a minority of users, has an easily implemented alternative solution, there is not an immediate business case for doing that, and there would likely not be enough firmware space free to have the duplication and additional code needed..

The alternative solution is for the user to place an 08M2 or other PICAXE chip between the RF receiver and the main PICAXE which can do the RF SERIN with qualifiers and no timeout, and only pass received data on to the main PICAXE when valid data is received. This filters out the RF noise which prevents the timeout firing in the main PICAXE and allows the main PICAXE SERIN code to work as desired with timeouts.
Code:
                    .-------------------| Do
                    |                   |   SerIn  RX, ( qualifiers ), data
                    |                   |   SerOut TX, ( data )
                    |                   | Loop
                    |
                    |            .------| Do
\|/                 |            |      |   SerIn [timeout,time], RX, data
 |    .----.    .------.    .--------.  |   :
 `----| RF |--->| 08M2 |--->| PICAXE |  | Loop
      `----'    `------'    `--------'
 

matchbox

Senior Member
The firmware is highly optimized for handling a serial input bit stream and changing the way timeouts are handled would mean duplicating a lot of code to handle both with and without qualifiers.
I'm aware of every work around possible and have been doing so for many years with RF links. I'm really surprised this feature isn't requested more for wireless communication between picaxe's.

I know the feeling of using duplicated code to overcome command inadequacy;) Maybe I'm just expecting too much of a system that was not designed for what I'm asking of it.
My issue is... I have so many old picaxe projects that still work great after all these years, but need refinement. If I have to make a hardware change, then I may as well change to a different hardware and code type. Because it would require me to design new boards.

Thank you for the advice. I appreciate your reply Hippy:)
 
Last edited:

hippy

Senior Member
Maybe I'm just expecting too much of a system that was not designed for what I'm asking of it.
That's about the bottom line of it. We never imagined the PICAXE would ever be used with dumb RF modules, never designed the firmware for such use.

I have so many old picaxe projects that still work great after all these years, but need refinement. If I have to make a hardware change, then I may as well change to a different hardware and code type. Because it would require me to design new boards.
Cutting the track between RF module and PICAXE, inserting another PICAXE in its path, isn't the hardest modification to make, though we appreciate it is still a modification. While not as cheap as may be desired the surface mount 08M2 module would allow such a modification to be done with minimal effort -


Other alternatives might be to move the serial input to the HSERIN pin and implement one's own byte by byte reception of data with timeout handling layered on top.

Sometimes moving to different hardware may be the best course but one has to consider the effort of a code rewrite and whether the software there delivers any better than the existing solution does.

If you can detail the code you have and what you need it to do I am sure members here will offer what help they can and suggestions for what they believe your best option would be.
 
Top