ZeroTier Networking

[coupe]

Updated github to make the verticaltrend averaging to update faster. I was only averaging if the values were different.

[coupe]

I've noticed the track level off and it's taking way too long for trend to zero. The Air2Air comes from the DF0 and DF16 which transmits altitude for TCAS. You should be seeing a lot of those. More than the ground radar DF4 and DF20 altitudes.

EDIT: Well I watched again and the Air2Air was about 1/4 the Altitude. I guess we have a lot of radars in this area.

[Oblivian]

Probably broken something not bothering to update the metrics, Callsign and ModeStable down the track. (there's been a few insert errors already) but got the 8yrs + new stuff massaged in together. I doubt a proper playback would work

Happy chap.


If I wanted to try harder I would have re-ordered all the auto increment records. But possibly break other stuff.

For some reason the Air2Air seems to get very little action. (might be my decode method) and altutude trend was a bit slow to update the target table I was pulling. So went back to a +/- 0 number rate method

[coupe]

P.S. there is an added metric for Type 7 Air to Air count. These are the Altitude squitters, not dependant on a ground site. FYI.

[coupe]

Did I mention I hate databases? ha. OK, off to bed. Have to get a haircut in 8 hours... à plus tard...

[Oblivian]

BiNGO
1599037181772

GMT: Wednesday, 2 September 2020 8:59:41.772 AM
Your time zone: Wednesday, 2 September 2020 8:59:41.772 PM GMT+12:00 <- HUZZAH a match

Now to clean up all the ones in the middle and import the last weeks of sqlite

[coupe]

OK, just uploaded ADSBMysql update to github. Hope it works!

[Oblivian]

Did I not mention this was Mysql not sqlite

Bed first. Head scratching later! be like me and save late ones for weekends

[coupe]

OK I uploaded a new version to ADSBSqlite to github without the zulu computations. Let me know how that works. It works OK here. (I think).

[Oblivian]

That may explain it. Cause local is out by -12 (auto deduction of TZ) so total -24 once UTC grabs hold

Mysql may have gotten smart and realised depending on the code used to convert it to and auto adjusting again from what you give it

[coupe]

It could very well be, that since I am no longer loading a string date into the table, my subtracting the ZONE and DST is no longer necessary. Hmm. I'll have to experiment. It could be my problem.

[Oblivian]

Locals time is correct on pc but for some reason stamps are 24hrs out from local. So decoded thinks it's yesterdays date (incorrect local 7am/12hrs off)


You've made me second guess now - 8.251

But I couldn't recall if I expanded the whole dir or just the .jar so just over-wrote it now incase. Same same

Even stranger from targethistory. With a from_unixtime(utcfadeout/1000) beside (Think that does local adjust). Which seems to as it also throws it 12hrs off current.. So right day, wrong time

C82764

1598988395263

1598988435309

2020-09-02 07:27:15.3090

1325

ZKLJT

I'd expect GMT to report 0700 on 2-9..

1598988395263 - GMT: Tuesday, 1 September 2020 7:26:35.263 PM

Might be because I'm on a +12 zone. I'll see what effect force setting the SQL server to different ones does.

[coupe]

Curious, Which version of Java are you running? Maybe check your BIOS clock setting?? I'm headed to bed, but will check my times tomorrow. It looks like it is writing local time into the database maybe??

[Oblivian]

Prepare for some real twilightzone..

Currently 741PM here. Wed 2-9

1598988804576 =
GMT: Tuesday, 1 September 2020 7:33:24.576 PM
Your time zone: Wednesday, 2 September 2020 7:33:24.576 AM GMT+12:00

And fun fact, you can set the next auto-increment number using

ALTER TABLE tablename AUTO_INCREMENT = 1

[Oblivian]

That's kinda how I spotted it. Ill throw up some comparison results at some point.

Brand new schema. Import old data (but had to convert it from plain text like it was in VarChar to bigint) which may have been the downfall.

Side by side the same select got me results for the last day of capture (22-8). Which gave hope as it appeared both were basically now identical. One on bigint/new schema + new mysql. And the old on the old schema + old sql


Putting new times into an epoch converter to confirm both the text record and unixtime record were the same. Which should have made for a correct +12hr display once adjusted

So fired up the new capture. And all of a sudden the next new record milisecond unixtime reported as 7pm (time of capture) rather than 7am.

But as long as the timestamp comes from local and adjust so should always be right. It's obviously going to be dependant on my server settings and query methods.