Inconsistent operation

[jimmie11]

I have a sensor which outputs data continuously every 7 ms. I know this is accurate because I am using the same sensor on a PC and the message comes from the sensor every 7 ms.

I modified one of your examples to read from that sensor and the code is attached. As you can see, every 10 (or so updates), something happens and the code does not update for over 100 ms.

What is causing that? Is it my code or the library?

Thanks in advance.
output_2023-06-02_09-11-47.log
QNTest.zip

[ssilverman]

First question: you're basing your application on the altcp-based example. Do you need TLS?

[jimmie11]

Hello Shawn: Thank you very much for responding, I appreciate it. I am a newbie. A friend of mine has written that code and I do not even know what TLS is! What do you recommend? Thanks again.

…

On Fri, Jun 2, 2023 at 5:09 PM Shawn Silverman ***@***.***> wrote: First question: you're basing your application on the altcp-based example. Do you need TLS? — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG5ZBNZIYJAJ6MXF635Q7PLXJJJB3ANCNFSM6AAAAAAYYMGH5U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ssilverman]

I really don’t think the problem is with the QNEthernet library. Is it possible you’re either dropping packets, or maybe the sensor just takes a while to respond? Are you polling for received data fast enough?

Can you describe exactly what you’re trying to do in a sequence of steps (possibly referring to each other, eg. for “repeats”). Describe what’s connected, the protocols you need, how communication needs to be done, and what you want done with the received data.

What I’m hearing right now is that your code doesn’t work, you don’t know why, and that someone else wrote it. Does the person who wrote it have any thoughts?

[jimmie11]

I had attached the code I am using to the PJRC forum you responded to.  I will attach it again on GitHub when I return. Basically, I connect to the sensor then issue a command so the sensor sends its data continuously.  I only write once to the sensor after which it starts streaming its data every 7 ms.After that I simply capture the data to a buffer and decode it.  Pretty standard. There is no polling. The problem cannot be with the sensor because I did the same thing with .NET.  The sensor sends its data reliably every 7 ms.  I tested over a few million messages.  Over 99.9 % of the time, data was sent every 7 ms. If it helps, I can give you remote access to the sensor and the PC it is connected to over a lan.Thanks again.On Jun 2, 2023, at 6:26 PM, Shawn

[jimmie11]

Here is the code.
testCode.txt

[ssilverman]

Do you have any documentation on the sensor and how it communicates?

[ssilverman]

I'm also not seeing the program print what's in the log "number Diff: number"
I think I'm missing a bunch of information here.

[jimmie11]

Attached is the document explaining the telegram sent by the sensor. It is a very long document but you only need pages 112-115 which explains parsing in my code.

The code I attached is the running code I am using. There is nothing missing other than the tls_template.c which is attached.

==================================================================
telegram_listing_telegram_listing_ranging_sensors_lms1xx_lms5xx_tim2xx_tim5xx_tim7xx_lms1000_mrs1000_mrs6000_nav310_ld_oem15xx_ld_lrs36xx_lms4000_lrs4000_multiscan100_en_im0045927.pdf

[ssilverman]

Maybe the problem is with the readBytesUntil() call? (Note: I haven't dived too deeply yet because lack of time right now; just trying to point out some possibly-obvious things to me.) That does a timedRead() call internally, which waits up to the Stream's timeout value (I think the default is 1 second) for data. I believe a state machine would run better than waiting on any call. In fact, that's how I write most of my code that reads from external equipment (I've written lots of drivers that talk to hardware having various protocols); it never has calls that wait or delay.

[jimmie11]

Thank you Shawn. You have gone beyond the call.

You mention ".....I believe a state machine would run better". I do not know what that is. Can you please refer me to how this may be used?

Can the readBytesUntil() call problem be fixed by specifying a very short timeout for the timedRead()? That sensor is continuously outputting data so would a timeout of a few ms fix this issue?

Thank you.

[ssilverman]

What I meant by not having all the information is that the log doesn't match what the program outputs. The log has "Diff:", but the code prints "Difference:". Basically, the first thing I see is that we're not looking at the results of the code.

[jimmie11]

Oh, I understand now! I made changes to the Serial.print statements thinking that it was the potential cause of the delay. The program logic is the same though ....

I am traveling and do not have access to the sensor so as soon as I return tomorrow, I will send the exact log corresponding to the code.

Thank you.

[ssilverman]

I’ll add: TCP isn’t a real-time protocol, so sometimes delays are to be expected. I’m going to convert this issue to a discussion because I think that’s more appropriate. I’ll create an issue if necessary in the future.