Speeding up transmission

[MaorKeshet]

To start with - I'm not a programmer, so please bear with my semi professional terminology.

SETUP: The SPJS is used to control local hardware from an HTML5+jc application. The application is running locally on Windows7/Chrome. Baud Rate is 9600.

The typical command is very simple:

PROBLEM: On the peak of my application's activity I send to the SPJS one command string every 150 ms. I didn't think that sending such simple commands that are 150 ms apart would be a problem on a local setup, but the SPJS takes about 750 ms (!) to actually transmit each of these short strings to the hardware controller. I have tried setting "default" and "tinyg" buffer algorithm, but it only made things worse.

Is there a way to shorten this latency on the transmission?

[johnlauer]

Maybe help me better understand how you're measuring the 750ms because that seems slower than what I experience when I use Chilipeppr to jog my CNC machine. I've never actually measured though.

Are you sure that you're not measuring the round trip and the pausing that occurs to not overflow the buffer in tinyg? You're saying you tried default, but it made it worse? You're saying default made it actually have a longer ms delay? That just sounds odd.

What are you running at 9600 baud btw? That's a very slow baud rate.

[MaorKeshet]

I am measuring the time that passes from the moment I send the string from the main app to websocket, to the moment the line serialport.go:240 appears on SPJS. I'm not sure about the roundtrip question. But I am trying to avoid buffering altogether.

When I make 750 ms pause between my commands the server buffer has time to clear between the commands and the result stays is in-sync and quite stable.

Any pauses shorter than 750 ms, the commands queue in the buffer and the result is out of sync, and also not at a stable rate. It turns out that each command eventually takes about 750 ms to transmitte.

What is the server process time (from string received to serial command sent) you are expecting on such setup?

Regarding the default buffer - I might be missing something here. Will test it again.

The Gauzy.com glass controller I have to control works at 9600, and honestly I don't think that the lossy cheap line that the client have implemented on site is feat for a higher baud rate...

[johnlauer]

It sounds like you're basing the 750ms on gut feel rather than a true measurement. Keep in mind that if you're using Chilipeppr or the Serial Port Widget that it waits to send the next command until it has seen a return ID number come back from SPJS. I'm guessing you're measuring that rather than time from send to getting to the serial port. You don't actually need those IDs. They're simply there to ensure that if you want your packets ordered that you have a receipting mechanism. If you don't want or care if they're ordered then ignore them and do your own implementation.

[MaorKeshet]

The sequence of commands is timed and sent independently from my the main app so waiting for ID is not the case.

I guess I'm missing something about the logged actions. Which of the lines states that the command was transmitted to the sp? I timed line 240, so maybe that's why I thought the transmission was slow... Can you please specify what each of these lines actually means?

[johnlauer]

I think we're kind of going around in circles here. I need a video to help you further because I'm just not sure what you're after or how you're measuring. I think 750ms seems way too slow for how fast and efficient SPJS is and my gut tells me it's the way you're measuring, so for me to help I'd need way more help from you on what you're doing via a video because screenshots of the logs just don't help me.

[MaorKeshet]

Yes I understand that.

Can you just tell me which of these lines indicates that the command was transmitted to the sp?

[johnlauer]

The source code is readily available for you to review. Go check the lines in the source code that the log shows so you can decide what you want to measure.

[MaorKeshet]

"To start with - I'm not a programmer" ... LOL

well, you have challenged me, I will take a look. thanks.