UDP Data Stream question

[Terence Dowling]

I'm observing that the timestamp in the data stream is gradually drifting so that 

the timestamp in my data stream is about 700 seconds behind real time.

I've tried using a python program derived from the sample as well as

a C program. Results (the discrepancy) are identical.

MyShake seems to be on-line and correctly reporting data (and the computers

reading the data also have "correct" time).

My system is R5A78 (Island of Hawaii about 70 miles from the volcano).

[South Franklin Weather Tasmania]

Hi same here,

I first noticed it about a week ago when my RAA90 4D upgraded from ver.11 to ver.12.

However I only noticed it when comparing against WinSDR outputs. Another shaker I am in contact who has same setup as me, was still on Ver.11 and did not have drift.

however yesterday his shake 4D upgraded to Ver.12 and he now sees the same drift.

I have over the last week observed approximately 2.5 seconds per every 5 mins drift behind.

Initially I thought it must be just WinSDR, though maybe it is the Shake ?

Note: I have latest Turnkey 4D with no GPS.

kind regards,

Tony

[Glenn McKechnie]

Terence Dowling wrote:
> I'm observing that the timestamp in the data stream is gradually
> drifting so that the timestamp in my data stream is about 700 seconds
> behind real time.
>
> I've tried using a python program derived from the sample as well as a
> C program. Results (the discrepancy) are identical.

Just as another POR.

This station (RC98F) is okay, it's running better than the local train
timetable (but then what doesn't?)

This is a 1D running version 0.12
Using tcpdump and getting the result as the TS string rolls over gives
these 2 entries.

sudo tcpdump -vvnnXs 0 'port 55555' | grep -B8 0x0060

05:35:11.744033 IP (tos 0x0, ttl 63, id 25732, offset 0, flags [DF], proto TCP (6), length 428)
[...]
0x0050: 2c0a 2022 5453 223a 2031 3532 3837 3831 ,.."TS":.1528781
0x0060: 3731 312c 0a20 2244 5322 3a20 5b0a 2020 711,.."DS":.[...

converting the epoch (TS) to formatted...
date -d @1528781711
Tue 12 Jun 05:35:11 UTC 2018


05:35:12.645052 IP (tos 0x0, ttl 63, id 25735, offset 0, flags [DF], proto TCP (6), length 428)
[...]
0x0050: 2c0a 2022 5453 223a 2031 3532 3837 3831 ,.."TS":.1528781
0x0060: 3731 322c 0a20 2244 5322 3a20 5b0a 2020 712,.."DS":.[...

again, converting the epoch to formatted...
date -d @1528781712
Tue 12 Jun 05:35:12 UTC 2018


ntp is configured as...

cat /etc/ntp.conf
[...]
server 192.168.1.60
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
[...]


# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.60 .GPS. 1 u 567 1024 377 1.495 -0.265 0.046
-144.48.166.166 126.11.196.147 2 u 241 1024 377 48.849 3.413 2.755
+129.250.35.251 249.224.99.213 2 u 355 1024 377 39.770 1.387 1.918
-27.124.125.252 27.124.125.250 3 u 722 1024 377 80.920 3.157 2.069
-116.206.80.123 223.252.32.9 2 u 1077 1024 377 38.783 2.922 0.586
-121.0.0.42 3.99.249.66 3 u 383 1024 377 53.795 -6.666 11.430
+150.101.178.79 172.22.254.53 2 u 655 1024 377 69.749 2.023 0.480
#52.65.237.49 133.243.238.164 2 u 230 1024 177 38.689 -12.542 2.852
2406:da1c:b32:4 .INIT. 16 - - 1024 0 0.000 0.000 0.000
2001:44b8:60:12 .INIT. 16 - - 1024 0 0.000 0.000 0.000
2402:1f00:8100: .INIT. 16 - - 1024 0 0.000 0.000 0.000
2a00:fd80:aaaa: .INIT. 16 - - 1024 0 0.000 0.000 0.000
-52.64.149.91 103.239.8.22 2 u 227 1024 377 38.682 3.332 2.314
-180.150.58.164 192.168.1.5 2 u 246 1024 377 66.280 2.064 1.997
-13.55.50.68 203.206.142.65 3 u 316 1024 377 38.788 1.864 0.614
#116.206.83.243 203.35.83.242 2 u 621 1024 377 38.793 -0.609 2.243


--

Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

Sorry, no fortune this time.

[Richard]

hi,

other reports were also received yesterday, so we are now very aware of this issue and will be looking into it post-haste.

thanks for the reports, i will be updating this thread when i have more information.

cheers,

richard

[Richard]

hi again,

problem has been identified and a push of the fix will be made very soon.

instructions will be sent individually on how to get it sooner than later.

apologies for the inconvenience, thanks again for the reports.

richard

[Terence Dowling]

Thanks for the prompt attention and FIX

[South Franklin Weather Tasmania]

Hi Richard,

Thanks for quick response and fix, received your email this morning. Re-Booted and all seems to be fixed, times no longer drifting.

Greatly appreciated,

Kind regards,

Tony RAA90 4D (Tasmania)

[Branden Christensen]

Rock and Roll! 

Love it. I wish every problem was this simple to fix and received this much appreciation ;) It is also great to hear that there are Shakers out there using the UDP functionality. 

Thank you all for your support and positive feedback. Serves as fuel for the team here in Panamá, many of which pour a lot of their hearts and souls in the Shake project. 

Buenas noches, 

Branden Christensen

Director, Raspberry Shake project, Social Media: @raspishake

USA: +1-845-418-5735; Panamá (Whatsapp): +507-6747-1427

--
Some useful links:
 
Manual: http://manual.raspberryshake.org/
Do It YourSelf Page: http://raspberryshake.org/do-it-yourself
Shop: https://shop.raspberryshake.org/
Website: http://raspberryshake.org/
 
Instagram: https://www.instagram.com/raspishake/
Facebook: https://www.facebook.com/raspishake/
Twitter: https://twitter.com/raspishake/
Hashtag: #rasperryshake, @raspishake
DOI: https://doi.org/10.7914/SN/AM
---
You received this message because you are subscribed to the Google Groups "RaspberryShake" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raspberryshake+unsubscribe@googlegroups.com.
To post to this group, send email to raspberryshake@googlegroups.com.
Visit this group at https://groups.google.com/group/raspberryshake.
To view this discussion on the web visit https://groups.google.com/d/msgid/raspberryshake/10f647cb-8494-4fdf-b684-8ac195496f0d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[South Franklin Weather Tasmania]

Hi Branden,

Glad the Team got a deserved boost :-)

I should however add that unlike Terrence, who started this thread, I am not using UDP but rather TCP/IP with WinSDR.

Which now does not drift after your fix, greatly appreciated,

Kind Regards,

Tony RAA90 4D 

[Larry Cochrane]

Hi Tony,

My WinSDR Server uses the UDP packets internally to the RShake. This data is parsed and sent to WinSDR using a TCP/IP connection,

Regards,

Larry Cochrane

Redwood City,PSN

[South Franklin Weather Tasmania]

Hi Larry,

Thank you for correcting me, appreciated.

Kind regards,

Tony

[Richard]

==== previous attached version was buggy, if you downloaded it, please delete and replace with new version in next post =====

hi,

after a couple of reports of dropped UDP data packets, i have extended the sample python program to monitor and measure any dropped packets; it is attached.

execute on a computer not the Shake Pi, that has been registered to receive the UDP data stream.  the receiving port should be specified in the variable at the top of the program.

execute as:

> python shake-UDP-packetLoss.py

cheers,

richard

[Richard]

here is the version that will work better (that's one way to describe it)...

richard