hello,
first, i can indeed confirm your observations regarding the differences between data packets’ contents that you are seeing:
- using the UDP protocol, data packets are delivered at a constant rate of one packet every 1/4 second, containing 25 data points per packet
- while using the seedlink protocol, the data packets delivered are not constant, but variable: both in how often they are delivered and the number of data points contained within each
the reason the seedlink data packets are variable is historical: seedlink, forever, has used the mini-SEED seismic data format. this format is indeed (very) compressed, though using an algorithm that is specific to seismic data only. because it was originally designed to minimize the amount of disk space needed to store the data, (long before there was live data streaming and, probably, long before anyone was even thinking about such things as EEW services), it does not perform well when the requirement is “give me the data as quickly as it comes off the ADC”.
in brief: seedlink data packets are delivered only when a mini-SEED data packet has been completely filled. because of how the mini-SEED compression algorithm works, this means that, for quiet data, more data points will fit into a single data packet than that for noisy data. in other words, latency between data packets is greater during quieter times than noisier times.
since EEW systems are interested in the noisier moments, this is good. however, this (slight?) decrease in data latency during an event of interest will never be enough to satisfy the requirement to have the data delivered as quickly as possible.
in short, if EEW services are your ultimate goal, where data latency must be minimized to the greatest extent possible, i cannot recommend using the seedlink protocol, it simply cannot provide the type of performance required.
that said, while “instant data” is very sexy, maybe the question can be turned around, to: “how much latency could actually be tolerated?” of course, this is also tricky since the answer to this question very much depends on the distance between event source and the people needing to be warned of impending shaking, the closer they are to the source, the less tolerable any data latency will be.
moving back to UDP, your concern regarding packet loss is real, since this is exactly what UDP is designed for. however, it is entirely possible that, although there is no guaranteed delivery, very few data packets will be dropped in practice; this can and should be measured (see the sample python programs in /opt/settings/user directory for example programs you can use for this). as well, even though TCP guarantees delivery, it does not guarantee timely delivery, it can ultimately be as late as it wants to be.
because i am unable to provide any absolute answers here, i would suggest setting up your own tests to measure each solution’s performance to determine what could work for your use-case:
- what percentage of UDP data packets are lost in a real-world scenario? (carried out for a relatively long period of time, say, at least a week)
- what is the average data latency when transferring data via seedlink?
- how much data latency can be tolerated?
- is there any possibility to use both protocols to deliver the data to your server?
and while i’m here, this seems like a good time to remind everyone reading this thread that while we at Raspberry Shake have no control over how you use our instruments, nor how the data generated by them is ultimately used, we very explicitly absolve ourselves of any responsibility and liability when used for any purposes beyond that of hobby. this is stated in the usage license here, in the last section titled “LIMITED LIABILITY & UPTIME”.
to be even more clearer (sic), the last paragraph of this section of the license states:
“… the Shake network is not to be used as an early warning system. While we cannot stop you from using it in such a way, we must state that using the network for reasons associated with saving human lives is not how it should be used. Furthermore, we refuse to accept responsibility for any negative outcomes due to the network being unavailable at any given moment.”
i hope that i have sufficiently addressed your questions, please let me know if not.
cheers,
richard