AcarsDeco2 Development

[Hobbyd]

Hi Sergsero,
Thanks for the new version and you ongoing effort to enhance the program.

Although I considered myself a software guy I am a bit confused.
I do understand the client-server model as well as UDP messaging.
So the options --outServer and  --outConnectUdp are clear to me.
But I would appreciate some explanation on what you mean with this --outConnect option.
As its arguments holds a 'host' value it looks like an UPD or ar least some sort of push protocol, were "host:port" is the target machine.

Cheers,
Dick

[sergsero]

Hi Dick,

1. The name of connection is determined depending on data direction in relation to the acarsdeco2 program: (--in...) means "input" and (--out...) means "output".

Although other network protocols exist, now we say about a TCP/IP network. Using this method, the computer sending the data connects directly to the computer it is sending the data it to, and stays connected for the duration of the transfer. With this method, the two computers can guarantee that the data has arrived safely and correctly, and then they disconnect the connection.

2. The program has two methods of obtaining an external data:  (--inServer) – when listener (local server sockets) opens a port on the network and then waits for clients to connect to that port. Client pushes it data to program.
And (--inConnect) – when the program as a client makes handshake, establishes a connection and pulls a data from remote server.

3. Similarly own data of the program can be rebroadcast over network by two methods: (--outServer) –  sender (local server sockets) opens a port on the network and then waits for clients to connect to that port. In this case client pulls a data from the program.
And (--outConnect) – when the program as a client makes handshake, establishes a connection and pushes a data to remote server.

4. If instead of a standard TCP/IP protocol connection uses connectionless  datagram over UDP/IP, in options name add "Udp" --inServerUdp or --outConnectUdp.

Although in the case of UDP, this name --outConnectUdp is not entirely correct since with UDP the program can send messages, in this case referred to as datagrams, to other hosts without establishing connection in hopes that they are accepted via the specified remote address and port. This method of transmission does not provide any guarantee that the data you send will ever reach its destination.


In --help's description a host is a computer that is accessible over a network. It can be a client or a server. It is understood that each host has a unique identifier called a hostname that allows other computers to access it. Depending on the network protocol, a computer's hostname may be a domain name or IP address.

Best regards,
sergsero

[Hobbyd]

Hello Sergsero,

Thank you for the extended response. Much appreciated.

Cheers,
Dick

[Hobbyd]

Hello Sergsero,
New version looking good.
I have one question and observations.
Question: is there some documentation on the web interface? Would like to know the meaning of the green/blue bullets inthe most right column.

Observations:
1. I use the command from a script on a headless RPi and start it with crontab or using SSH:
/home/pi/acarsdeco2_20170907/acarsdeco2  --no-console --device-serial 12 --freq-correction -2 --freq 131525000 131725000 131825000 --http-port 8888 --logfile /home/pi/acarsdeco2_20170907/logs/test >> "/home/pi/acarsdeco2_20170907/logs/process-acarsdeco2.log" &
I was hoping/expecting to see all (except the acars messages) in the file "process-acarsdeco2.log". However some program messages are displayed on the console and not in the file.
Did I do something wrong? 

2. The flights/records on the web interface do not seem to timeout.
All records since starting the program (10 hours ago) are still there.
Is that working as designed or is there a timeout setting I can use and have missed?

See attached screenshots.

Cheers,
Dick

[Attachment deleted by Admin to save file space]

[Hobbyd]

Hi Sergsero,

As to the first observation:
I changed the end of the command from" & " into " 2>&1 &".
Now all program output is redirected to the file specified behind the "  >>  ".

Cheers,
Dick

[acarslogger]

Hi sergsero

Thanks for your latest version of acarsdeco2. I'm using release 20170907 on windows and monitoring the output using the --OutServer and --OutConnectUdp parameters.

The OutServer options are OK. I get an ascii output in comma separated format
date,time,frequency,mode,registration,ack/nak,label,blockid,msgno,flightid,acarsmessage

The sbs format contains spaces in place of carriage return/line feed.
The ad2 format retains the CR/LF.

When I use the --OutConnectUdp ad2 parameter I get an ascii output in the same format as above, with CR/LF retained.
However when I use the --OutConnectUdp sbs parameter I get an ascii output in the following format using space separated

ADmode registration ack/nak label blockid msgno flightid acarsmessage

The acars message has CR/LF replaced with a space. But there is no date and time.

Should the OutConnectUdp sbs format be comma separated and include date and time fields ?

Regards
Stuart

[Hobbyd]

Hello Sergsero,
Two observations:
1. all log entries contain "SOURCE: AIR", also the uplinks like squitters.
If that is correct then what does "SOURCE" mean?

2. The process log where all program messages are redirected to is filled with records like these:
"2017-09-16 14:12:47.603  ERROR    AircraftCache::getAircraftsList(): regno in DB but not in cache"

Cheers,
Dick

[sergsero]

Hi Dick,

The option --no-console disables display of received messages on the screen, but not a service information of the program. Use additional redirection in the command line if you want to redirect all. However, remember that the "1" denotes standard output (stdout) and the "2" denotes standard error (stderr). So 2>&1 says to send standard error to where ever standard output is being redirected as well.

The color of bullets indicates the time interval in minutes since the last message was received - green: 0 < t < 5 min, blue: 5 < t < 60 and grey: t > 60 min.

The program keeps in memory the information about the received messages for 12 hours (± 5 min).
Note. In this version, uniqueness of the record is determined only by a registration number of the aircraft. In next versions will additionally use the flight number.

Source here means that the data were been obtained through own receiver (AIR) or via a network (NETWORK).

I'm working on the issue "error AircraftCache::getAircraftsList(): regno is in DB but not in cache" in program code. Although not able to reproduce it in my tests.

Regards,
sergsero

[sergsero]

Hi Stuart,

The formats of output messages via a network.

In the current test version 20170914 (see below) I added new format for PlanePlotter as pp. So now, in some options you can use three different formats: sbs | ad2 | pp.

I check the order of characters in the program's formats based on output to network data in the original programs Basestation.exe and Planeplotter.exe.

On the first screenshot, messages were decoded and sent via network by two sources: Planeplotter.exe using its audio input (at the bottom) and receiver SBS-3 through the program Basestation.exe (at the right top).

The second screenshot is internal representation of the same messages within these programs. The timestamp of message received is present in Planeplotter, but it's not sending via network.

Now you will be able to use UDP protocol to transmit messages, which have comma separated components and include date and time fields - the third screenshot.

Regards,
sergsero


[Attachment deleted by Admin to save file space]

[sergsero]

Hello,

Thank you very much for testing!

Best regards,
sergsero

[Hobbyd]

Hello Sergsero,
Thank you for the extended explanation.
As always much appreciated.

As to the `regno in DB but not in cache` messages±
A closer look in the process log shows that there is only one set of 2050 of these message. It seems some sort of loop.
The time of the first error message:
"13:39:02.540  ERROR    AircraftCache::getAircraftsList(): regno in DB but not in cache"

is only milliseconds after this message:

SOURCE: AIR
RX_ID: 1352, Freq: 131.525MHz
ACARS mode: t (116), label: SQ (Link test message)
Block id:   (32)
Aircraft reg:       

Message content:-
02XSCDGLFPG04901N00233EV136975/
-------------------------------------------------------[2017-09-16 13:39:02.295]

There is only one "label: SQ" message in this log.
Maybe it is related?

Cheers,
Dick 

[Radio2.0]

@Hobbyd
I reccommend to use that freq: --freq 131525000 --freq 131550000 --freq 131725000 --freq 131825000 --freq 131850000

So I ask again:
1) does anything change on the Decoder?
2) Can you add an output thing to put it out as an CSV File? It would make my life easier.

[Hobbyd]

Hello Radio.2

I am confused by your

"@Hobbyd
I reccommend to use that freq: --freq 131525000 --freq 131550000 --freq 131725000 --freq 131825000 --freq 131850000 "

In my area there are only 3 active acars freq's and I have them configured like this:
"--freq 131525000 131725000 131825000" which works fine.

The two questions you ask (again) can only be answered by Sergsero.

Cheers,
Dick

[acarslogger]

Hi sergsero,

Thanks for response regarding the sbs | ad2 | pp output options.

I'll test the new test version.

Thanks
Stuart

[sergsero]

Hi,

In these test versions in code completely rewritten the network part and interface. In decoder was made optimization computing for Intel CPU and now used some intrinsics, that refers to functions that are built-in and most standard library functions that the compiler can/will generate inline instead of calling an actual function in the library.
Perhaps, if time allows, I'll make improvements in the code for ARM processors.

Data output to file in CSV will be realized in next versions.

I note, that unfortunately, in my area not available for receiving messages from ground stations (ground-to-air) and the associated functionality is not tested in practice.

I'll be waiting on tests results and feedback.

Regards,
sergsero