Trace data from seedlink too slow

[haidar mansur]

Problem

I’m using handle data trace but the response is about 1 sec or more.
So how to get realtime data or faster data trace for examlpe per 200 milisecond ?

Proposed solution

Can collect data less than 1 second

[Robert Pickle]

can you post your code?

going to guess that this is a FDSN server lag issue rather than something that can be sped up in obspy.

[haidar mansur]

from obspy.clients.seedlink.easyseedlink import create_client
# import numpy as np
import requests
import json
from obspy.realtime import RtTrace

def send_data_to_api(data):
    api_url = "http://localhost:8282/api/send_ws_ews"  # Replace with the actual API endpoint URL
    headers = {
        "Content-Type": "application/json",  # Replace with the appropriate content type if needed
    }

    try:
        response = requests.post(api_url, json=data, headers=headers)
        response.raise_for_status()  # Raise an exception if the request was unsuccessful (status code >= 400)


        # print("Data sent successfully!")
    except requests.exceptions.RequestException as e:
        print(f"Error sending data to API: {e}")

def handle_data(trace):
    channel_code = trace.stats.channel
    #print('Received the following trace:')
    trm = trace.data
    tr = trace.data[0:10].tolist()
    mean = trm.mean()
    json_tr = json.dumps(tr)
    # peak = np.amax(np.abs(tr))
    data_to_send = {
    "channel_code": channel_code,
    "mean": json_tr
    }
    send_data_to_api(data_to_send)
    # print(mean)
    print(f"Mean amplitude for trace {trace.id} ({channel_code}): {mean}")
# Connect to a SeedLink server
client = create_client('192.168.1.41:18000', handle_data)

# Retrieve INFO:STREAMS
# streams_xml = client.get_info('STREAMS')
# print(streams_xml)

# Select a stream and start receiving data
client.select_stream('HP', 'GTN41', 'SH?')

client.run()

[Robert Pickle]

thanks. what are you using for your seedlink server? how and where are you measuring the latency, from receiving the trace or after it's sent to your API?

[haidar mansur]

I'm creating Web Apps to get realtime data from GeoBit GEOwarning, I don't know how to measuring the latency.

[Jollyfant]

Is the timing not just limited by the packet size of the Seedlink protocol? It needs to collect ~500 samples to pack and send 512 byte records, which at 100Hz might take a half second. If so, you can probably configure your Seedlink server to use smaller 128 byte packets without STEIM2 compression to fill up the packets faster too.

[Robert Pickle]

yeah, if you could reduce the record length that should theoretically speed things up, but I know for seiscomp at least the default seedlink plugin seems to be hardwired to 512.

could also try skipping the trm.mean() calculation to save some milliseconds but.... probably the lag is occurring everywhere but obspy. FWIW our server lag from source to disk tends to fluctuate between 0.5-3 sec and there is no obspy involved.

[haidar mansur]

you can probably configure your Seedlink server to use smaller 128 byte packets

but I got an error after setup MiniSEED packet: to 128 bytes, even i try different samples
negotiation with remote SeedLink failed: 'cannot negotiate uni-station, stream list does not have exactly one element'

[Jollyfant]

Yeah, like @filefolder said, the Seedlink client seems to be hardcoded to 512 bytes, I guess you could try modifying this value to your configured packet size (128) but no guarantees it will work: https://github.com/obspy/obspy/blob/master/obspy/clients/seedlink/slpacket.py#L65.

[haidar mansur]

Yeah, like @filefolder said, the Seedlink client seems to be hardcoded to 512 bytes, I guess you could try modifying this value to your configured packet size (128) but no guarantees it will work: https://github.com/obspy/obspy/blob/master/obspy/clients/seedlink/slpacket.py#L65.

Ok no problem I just increase the Samples and sensitivity to 8 g, and its faster Thanks.
and How about compression should I change from STEIM2 to STEIM1 ?

[Jollyfant]

I would go for FLOAT64 or simple raw 32-bit integers which should have no integer compression that STEIM1 and STEIM2 do.

[Tobias Megies]

Yeah, the worse your compression is, the lower your latency might go ironically, since fewer samples will fit in one packet. Obviously that's hurting your bandwidth in the process, so keep that in mind in case of slow or metered connections. 🤣

[obspy-bot]

This issue has been mentioned on ObsPy Forum. There might be relevant details there:

https://discourse.obspy.org/t/trace-data-from-seedlink-too-slow/1760/2