Announcement

Collapse
No announcement yet.

ZeroTier Networking

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Leave a comment:


  • coupe
    replied
    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.
    Last edited by coupe; 2020-09-07, 13:24.

    Leave a comment:


  • Oblivian
    replied
    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

    Leave a comment:


  • coupe
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • Oblivian
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Oblivian
    replied
    Did I not mention this was Mysql not sqlite

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

    Leave a comment:


  • coupe
    replied
    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).

    Leave a comment:


  • Oblivian
    replied
    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

    Leave a comment:


  • coupe
    replied
    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.

    Leave a comment:


  • Oblivian
    replied
    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.

    Leave a comment:


  • coupe
    replied
    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??

    Leave a comment:


  • Oblivian
    replied
    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

    Leave a comment:


  • Oblivian
    replied
    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.

    Leave a comment:

Working...
X