ZeroTier Networking

[Oblivian]

I didn't mind the full blown. Got records back to 2012 people call upon to check historical stuff. Its fab.

Albeit the laptop with 2gb ram hates me

[Oblivian]

Managed to drop 20Gb of noise from the targetecho table. Less than 1Gb now for 7 history years isn't bad

Tried the SQlite 1.9 version along side the current receiver/setup (orignal Beast with beast-splitter like your example run originally)

Added modesdeco2 back in the mix, and switch between fr24feed being on/off and using modesdeco2 and doesn't log altitudes again. Dammit.

Must be something with my beast-splitter (or beast) options. Causing changes to the 30003 format between what fr24feed produces and everything else.

Perhaps time to see if radarcape format works despite not being one.

[coupe]

Yes, target echo is not very useful in the database. I use it to paint target data trails on the TrackView application. Do you have a few lines of the fr24feed syntax for Basestation compatible? I know there are about three different compatibilities. The ADSBNet program seems to work well with modesdeco versions, as I used that as the data. Most of the bad Basestation implementations mess up by not having enough comma's or leave the boolean values blank (emergency, hijack, etc).

[Oblivian]

Yep. This is pumping out of fr24feed at present - no issue capturing altitude and so on

But when I put others on (planeplotter and modesdeco2 for instance) it seems to not have an associated flight ID at the start (333) and additional ,s like you say

MSG,8,333,82,C8237A,182,2020/08/23,16:19:39.387,2020/08/23,16:19:39.387,,,,,,,,,,,,0 MSG,8,333,86,C8221A,186,2020/08/23,16:19:39.387,2020/08/23,16:19:39.387,,,,,,,,,,,,0 MSG,4,333,72,C81CB1,172,2020/08/23,16:19:39.387,2020/08/23,16:19:39.387,,,91.0,91.9,,,-192,,,,, MSG,3,333,86,C8221A,186,2020/08/23,16:19:39.487,2020/08/23,16:19:39.487,,7850,,,-43.32035,172.70279,,,0,0,0,0 MSG,8,333,84,C82727,184,2020/08/23,16:19:39.488,2020/08/23,16:19:39.488,,,,,,,,,,,,0 MSG,4,333,84,C82727,184,2020/08/23,16:19:39.488,2020/08/23,16:19:39.488,,,268.0,36.4,,,64,,,,, MSG,3,333,80,C822E4,180,2020/08/23,16:19:39.701,2020/08/23,16:19:39.701,,22525,,,-42.00799,173.94462,,,0,0,0,0 MSG,4,333,82,C8237A,182,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,,272.0,223.4,,,-1472,,,,, MSG,4,333,83,C82336,183,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,,227.0,43.2,,,-832,,,,, MSG,3,333,72,C81CB1,172,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,1100,,,-43.43715,172.38967,,,0,0,0,0 MSG,4,333,80,C822E4,180,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,,420.0,45.1,,,-2496,,,,, MSG,5,333,86,C8221A,186,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,7875,,,,,,,0,,0,0 MSG,4,333,86,C8221A,186,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,,332.0,36.8,,,2816,,,,, MSG,5,333,84,C82727,184,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,17000,,,,,,,0,,0,0 MSG,5,333,84,C82727,184,2020/08/23,16:19:39.794,2020/08/23,16:19:39.794,,17000,,,,,,,0,,0,0 MSG,3,333,84,C82727,184,2020/08/23,16:19:39.831,2020/08/23,16:19:39.831,,17000,,,-42.84682,173.18215,,,0,0,0,0 MSG,3,333,83,C82336,183,2020/08/23,16:19:39.831,2020/08/23,16:19:39.831,,13500,,,-44.04648,171.63123,,,0,0,0,0 MSG,4,333,72,C81CB1,172,2020/08/23,16:19:39.898,2020/08/23,16:19:39.898,,,91.0,91.3,,,-128,,,,, MSG,6,333,72,C81CB1,172,2020/08/23,16:19:39.898,2020/08/23,16:19:39.898,,1100,,,,,,2557,0,0,0,0

I've reconfigured beast-splitter to more an 'auto' mode incase what I had specified was doing something, and will see if the 30005 output being flagged as Radarcape instead of classic B has an effect on conversion to BS



At one point I've lost a few airborne contacts totally that FR24 seems to be able to MLAT. So guessing there may be some type DF18/20 only or 0/4/5 filtering (which is an option) kicking in on my splitter modes

[Oblivian]

I'm second guessing myself now.

Still in Radarcape 30005 connect format as above. But using modesdeco2 to BS instead.

MSG,4,111,11111,C8200B,111111,2020/08/23,16:52:22.000,2020/08/23,16:52:22.000,,,285.2,198.2,,,-128,,0,0,0,0 MSG,3,111,11111,C82726,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,11800,,,-43.87260,171.89209,,,0,0,0,0 MSG,8,111,11111,C82871,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,,,,,,,,0,0,0,0 MSG,4,111,11111,C82726,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,,262.9,56.0,,,-1664,,0,0,0,0 MSG,5,111,11111,C8276C,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,19675,,,,,,,0,0,0,0 MSG,4,111,11111,C82871,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,,285.2,218.9,,,-128,,0,0,0,0 MSG,3,111,11111,C8276C,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,19675,,,-44.19553,171.80230,,,0,0,0,0 MSG,3,111,11111,C8200B,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,22000,,,-42.59483,172.60569,,,0,0,0,0 MSG,4,111,11111,C8244B,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,,283.8,231.2,,,0,,0,0,0,0 MSG,3,111,11111,C8244B,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,15975,,,-43.11687,173.23635,,,0,0,0,0 MSG,3,111,11111,C82871,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,20000,,,-42.28633,174.16070,,,0,0,0,0 MSG,4,111,11111,C8200B,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,,285.2,198.2,,,-128,,0,0,0,0 MSG,5,111,11111,C82871,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,20000,,,,,,,0,0,0,0 MSG,6,111,11111,C82871,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,20000,,,,,,5725,0,0,0,0 MSG,6,111,11111,C82871,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,20000,,,,,,5725,0,0,0,0 MSG,4,111,11111,C82726,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,,262.4,56.2,,,-1664,,0,0,0,0 MSG,8,111,11111,C8200B,111111,2020/08/23,16:52:24.000,2020/08/23,16:52:24.000,,,,,,,,,0,0,0,0 MSG,5,111,11111,C8244B,111111,2020/08/23,16:52:23.000,2020/08/23,16:52:23.000,,15975,,,,,,,0,0,0,0

The java counter is now logging altitude detection, but not stamping to the dbase with it.

Odd.

[coupe]

I wonder if the Mysql connector driver is buggy. Maybe I need to compile with a different version?? They're up to 8.0.21 now.

[coupe]

I recompiled and uploaded changes to the github repository: https://github.com/srsampson/ADSBMySQL

I used Ubuntu 20.04 download at https://dev.mysql.com/downloads/connector/odbc/

I hope! ha. I'll have to test it tomorrow. Time for bed here.

[Oblivian]

It could also be the pure number of ,,, expected. Seems they adjust depending on what is being decoded. Which may point at my source receiver/config for all I know.

My current table is still 1.7 based, so missing a few of the extra columns added. (long process dumping to CSV and mapping back from vchar to bigint dates)

Hence using the 1.9 sqlite momentarily to check the difference. But when viewing the 'targets' table on either realtime via modesdeco, you can see it filling with -9999 alt or NULL.

And sometimes no callsign. As if it is offset to the wrong expected records. Unfortunately the cmd window doesn't spit out any write errors to be sure.
That said, I could check the sql logs..

[coupe]

I'll recompile the sqlite version tomorrow and see whats what.

[coupe]

I just ran the old version here, and altitude is updating in database using modesdeco2 and RTL SDR - FYI

[coupe]

Altitude updates in both mysql and sqlite I mean. Not sure what the danged problem would be. Maybe you hit a filesize limit in the OS...

[coupe]

P.S. I think you are the only one using this stuff. I haven't used it since last May. Been retired from adsb for a while. I'm receiving 1 track tonight, the police helicopter! ha.

[Oblivian]

Yeah. It beats me too.

Don't put too much effort

the writer and formatting seems right, But the data it's getting is offset somehow. Or ignored when not getting further ident packets to match with.

Assuming it looks for a specific column/space for alt.

Side by side from my 2 captures above it looks like it SHOULD be just fine - 2 message formats compared, Top line FR24, bottom modesdeco2

Lot's of 1s. Though but that may be just the session automatic.

'L' is mode-c altitude - present. So shouldn't be NULL when writing.
ll look at a MSG5 compared. Just incase I have something making it miss DF4/DF20

MSG,5

Surveillance Alt Message

DF4, DF20

Triggered by ground radar. Not CRC secured. MSG,5 will only be output if the aircraft has previously sent a MSG,1, 2, 3, 4 or 8 signal.

I've reverted back to 'auto' mode. I had some options forced.
When I start beast-splitter each addon is forever changing the modes however

serial(/dev/beast): configured with settings: BCDfgHIjk
localhost:30004: connected to [::1]:30004 with settings
serial(/dev/beast): configured with settings: BCdfGHijk
serial(/dev/beast): autobaud selected 3000000 bps

ala

B: Use Beast-Classic mode (see below)
C use binary format
d/D: no special filtering / send only DF11/17/18 messages
f/F: normal CRC checks
g/G: 12MHz timestamps / GPS timestamps (only in Radarcape mode)
H: flow control enabled (ignored!)
i/I: FEC enabled / FEC disabled
j/J: Mode A/C disabled / Mode A/C enabled
k/K: no special filtering / do not send DF0/4/5 (only in Beast-Classic mode)

[Oblivian]

Am I? damn lol

I find it super handy!. Taught me a lot about queries and PHP

Keeping an eye on 'stealth' contacts and people come to me for historic local data. or 'what was that' - I have it being pulled into pretty PHP pages

[Oblivian]

I'll just have to work harder to export and merge the last 5 years data into a new 1.9 formatted dbase with the new columns and different date/time types etc and see how it goes.

Would rather keep it a single and prevent the need to lookup 2 different tables for historic stuff.

Started last night, and some tables come across fine. But it doesn't like moving utcdetect from varchar to bigint