Buildin Server not comming up

[werwaswarum]

Hi, I would like to receive some TPEG and IP data over DAB. As far as I understood the doc, it should be possible to get these data on an IP port. Therefore, I build my own version under Fedora 39 in the qt-dab-RC folder, where I activate booth or just one functionality in the .pro file. Unfortunately, no server came up, and no port is open.

Furthermore, I realized that no map server is coming up for me either. Beside my own build, I tested the AppImage on the Fedora system as well as the Windows release version under Windows 10.

In any case, the HTTP button in the main widget stayed without function.

I would appreciate a point to what I miss starting the server.

Best regards, werwaswarum

[JvanKatwijk]

Hello You have different quations a. wrt the TPEG : if "datastreamer" is enabled then the code is included such that TPEG output is send ro port 8888. The data is packed, but that is clear from the sources After reading your mil I realized (well, after checking first) that the small client code was not part of the sourcetree anymore (It is anout 5 to 6 years ago that there was interest in TPEG) The client code is added to the sourcetree and the packed sources are included as attachment It is a simple interpreter of TPEG data packages, simple, because most TPTEG data is packed in proprietary ways

I would be very interested in getting some recordings with TPEG data, here in the Netherlands I do not find any TPEG service in the ensembles I receive

b. I assume you configured the input such that the tiiLib should be loaded, or you have a copy of the database installed If you do not have set your own location then the http button will do nothing, after all, without a reference point computing diatnces does not make much sense

If, however, you have either the tiilibrary installed and/or the copy of the database, and you still do not see a distance on the main widget (well not all transmitters carry TII data), then something is wrong

So, as mentioned above I am interested in processing TPEG

best jan

Op wo 20 mrt 2024 om 23:57 schreef werwaswarum @.***>:

Hi, I would like to receive some TPEG and IP data over DAB. As far as I understood the doc, it should be possible to get these data on an IP port. Therefore, I build my own version under Fedora 39 in the qt-dab-RC folder, where I activate booth or just one functionality in the .pro file. Unfortunately, no server came up, and no port is open.

Furthermore, I realized that no map server is coming up for me either. Beside my own build, I tested the AppImage on the Fedora system as well as the Windows release version under Windows 10.

In any case, the HTTP button in the main widget stayed without function.

I would appreciate a point to what I miss starting the server.

Best regards, werwaswarum

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQHTUQX6K7IYDI75RQLYZIH7DAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TQNZTHA4TSMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Jan van Katwijk

[werwaswarum]

Hi Jan,

Thank you for your help, although my issue was very confused. My idea was to have a look into datatransport in DAB. I found out that in Germany now Correction for GNSS are transmitted at Channel 5C PPP-RTK-AvD. So I started to take a look at your awesome software, and as no server for the datagrams came up, I tried TPEG with the same result and then I was trz to activate the map.

With the included TPEG client I see now data on the TPEG channels and can receive data on the socket, nice! I attched some .eti filed for channel 5C and 10B in northern Germany which include TPEG data. May I suggest to move the decoding into another Issue?

In the next step I would like to activate the datagrams, as far as I understood the docs I need to change the .pro file to

CONFIG += datastreamer

to handle output of embedded an IP data stream, uncomment

CONFIG += send_datagram

Unfortunately no port show up. Best, Lars

Qt-DAB-DR Deutschland -5C-Do--März-21-16-58-43-2024.zip Qt-DAB-NDR HH -10A-Do--März-21-17-02-06-2024.zip

[JvanKatwijk]

I'll have a look agt the datagram, it is pribably not used for 6 or 7 years

Op do 21 mrt 2024 om 17:28 schreef werwaswarum @.***>:

Hi Jan,

Thank you for your help, although my issue was very confused. My idea was to have a look into datatransport in DAB. I found out that in Germany now Correction for GNSS are transmitted at Channel 5C PPP-RTK-AvD. So I started to take a look at your awesome software, and as no server for the datagrams came up, I tried TPEG with the same result and then I was trz to activate the map.

With the included TPEG client I see now data on the TPEG channels and can receive data on the socket, nice! I attched some .eti filed for channel 5C and 10B in northern Germany which include TPEG data. May I suggest to move the decoding into another Issue?

In the next step I would like to activate the datagrams, as far as I understood the docs I need to change the .pro file to

CONFIG += datastreamer

to handle output of embedded an IP data stream, uncomment

CONFIG += send_datagram

Unfortunately no port show up. Best, Lars

Qt-DAB-DR Deutschland -5C-Do--März-21-16-58-43-2024.zip https://github.com/JvanKatwijk/qt-dab/files/14703715/Qt-DAB-DR.Deutschland.-5C-Do--Marz-21-16-58-43-2024.zip Qt-DAB-NDR HH -10A-Do--März-21-17-02-06-2024.zip https://github.com/JvanKatwijk/qt-dab/files/14703716/Qt-DAB-NDR.HH.-10A-Do--Marz-21-17-02-06-2024.zip

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2012895671, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQFNN6VVTQ4GFEZCRNLYZMDEBAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJSHA4TKNRXGE . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

[JvanKatwijk]

In the code I see that the default port to which IP data is sent is also 8888, which is obviously confusing. I used to have a raw input recording with IP data, but it seems to be lost. If possible, can you record a raw input recording ( the default sndlib in fedora seems to have problem with rates over app 200000, raw and xml are fine) with IP data, then I can trace the processing.

Anyway, it is fun to - finally - see someone who is interested in TPEG and IP data

best jan

Op do 21 mrt 2024 om 17:45 schreef jan van katwijk @.***>:

I'll have a look agt the datagram, it is pribably not used for 6 or 7 years

Op do 21 mrt 2024 om 17:28 schreef werwaswarum @.***>:

Hi Jan,

Thank you for your help, although my issue was very confused. My idea was to have a look into datatransport in DAB. I found out that in Germany now Correction for GNSS are transmitted at Channel 5C PPP-RTK-AvD. So I started to take a look at your awesome software, and as no server for the datagrams came up, I tried TPEG with the same result and then I was trz to activate the map.

With the included TPEG client I see now data on the TPEG channels and can receive data on the socket, nice! I attched some .eti filed for channel 5C and 10B in northern Germany which include TPEG data. May I suggest to move the decoding into another Issue?

In the next step I would like to activate the datagrams, as far as I understood the docs I need to change the .pro file to

CONFIG += datastreamer

to handle output of embedded an IP data stream, uncomment

CONFIG += send_datagram

Unfortunately no port show up. Best, Lars

Qt-DAB-DR Deutschland -5C-Do--März-21-16-58-43-2024.zip https://github.com/JvanKatwijk/qt-dab/files/14703715/Qt-DAB-DR.Deutschland.-5C-Do--Marz-21-16-58-43-2024.zip Qt-DAB-NDR HH -10A-Do--März-21-17-02-06-2024.zip https://github.com/JvanKatwijk/qt-dab/files/14703716/Qt-DAB-NDR.HH.-10A-Do--Marz-21-17-02-06-2024.zip

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2012895671, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQFNN6VVTQ4GFEZCRNLYZMDEBAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJSHA4TKNRXGE . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

-- Jan van Katwijk

[werwaswarum]

Hi Jan,

Thank you again for your support. I want to test if PPP-RTK-AvD contains ip data, as there is a leak of documentation. Never the less it is fascinating to me how much information are available on DAB.

I thought there is a huge interest in data services, especially in Germany, where cellular networks are not available everywhere. Find attach some raw measurements: https://www.transfernow.net/dl/20240321WEasy1TQ

[JvanKatwijk]

Hi Lars

Looking in my dusy archive I discovered a recording (French from 2017) with some IP data on it and when configuring it, Qt-DAB emits packages of 400 bytes. The current set up is to send it as datagrams over 127.0.0.1:8888, but that can be changes in the ini file

Thanks for the recording, today I'll probabaly too busy, but as soon as I can I'll give it a try

best jan

Op do 21 mrt 2024 om 23:48 schreef werwaswarum @.***>:

Hi Jan,

Thank you again for your support. I want to test if PPP-RTK-AvD contains ip data, as there is a leak of documentation. Never the less it is fascinating to me how much information are available on DAB.

I thought there is a huge interest in data services, especially in Germany, where cellular networks are not available everywhere. Find attach some raw measurements: https://www.transfernow.net/dl/20240321WEasy1TQ

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2013980892, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQFRKFSXFJUJPCUQJBTYZNPSTAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJTHE4DAOBZGI . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

[werwaswarum]

Hi Jan,

Would it be possible to test my build with these data? When the server then appears, I am sure that I set the right config in the make files. Another question that appears to me is how the console prints an App type, e.g., 1200, but I cannot find any information about the App types.

Looking forward to seeing where we can go on.

Best, Lars

[JvanKatwijk]

Hi Lars, It took a while, since I detected an error in the xml file handling. I upload the new sources in a inute

Wrt the data: very interesting, two TPEG channels and a channel unknown to me

You can look at - at least = the structure of the TPEG data using the client, it turns out that botht services are encrypred The "PPP-RTK-AdV" service shows an apptype of 1500, I never saw that before, so I'm going to look at it. Of course you can print out all headers by adding a few lines to the client code, but it remains encrypted

Again, Thanks for the recording, very interesting, it shows that I am living at 404 Km from the transmitter

Op za 23 mrt 2024 om 21:20 schreef werwaswarum @.***>:

Hi Jan,

Would it be possible to test my build with these data? When the server then appears, I am sure that I set the right config in the make files. Another question that appears to me is how the console prints an App type, e.g., 1200, but I cannot find any information about the App types.

Looking forward to seeing where we can go on.

Best, Lars

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2016593343, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQDMYJ22NYTOC7OQO6LYZXPZPAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGU4TGMZUGM . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

[JvanKatwijk]

have a look at https://www.digitalbitrate.com/dtv.php?mux=5C&pid=4494&live=155&sec=0&lang=en It tells how the packets are encoded, so later this week I'll see whether I can get some data visible

Op zo 24 mrt 2024 om 14:04 schreef jan van katwijk @.***>:

Hi Lars, It took a while, since I detected an error in the xml file handling. I upload the new sources in a inute

Wrt the data: very interesting, two TPEG channels and a channel unknown to me

You can look at - at least = the structure of the TPEG data using the client, it turns out that botht services are encrypred The "PPP-RTK-AdV" service shows an apptype of 1500, I never saw that before, so I'm going to look at it. Of course you can print out all headers by adding a few lines to the client code, but it remains encrypted

Again, Thanks for the recording, very interesting, it shows that I am living at 404 Km from the transmitter

Op za 23 mrt 2024 om 21:20 schreef werwaswarum @.***>:

Hi Jan,

Would it be possible to test my build with these data? When the server then appears, I am sure that I set the right config in the make files. Another question that appears to me is how the console prints an App type, e.g., 1200, but I cannot find any information about the App types.

Looking forward to seeing where we can go on.

Best, Lars

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2016593343, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQDMYJ22NYTOC7OQO6LYZXPZPAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGU4TGMZUGM . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

-- Jan van Katwijk

[werwaswarum]

Hi Jan, I playing around with TPEG reception in this minute :) With respect to the TPEG channels: There should be three TPEG channels TPEG. TPEG_MM in 5C and and TPEG ARD on 10A.

I could decode Version 1 from time to time by using the OpenLR python version: https://openlr-python.readthedocs.io/en/latest/index.html

My code:

import socket
import sys
import openlr
import base64

 HOST ="127.0.0.1"   # The remote host
 PORT = 8888             # The same port as used by the server

while(True):
    print(f"Run")
    try:
        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
            s.connect((HOST, PORT))
            data = s.recv(2048*32)

        test= base64.b64encode(data)
        print(openlr.binary_decode(test, is_base64=True))

    except NotImplementedError:
        print(f"Version Error")

    except ValueError:
        print(f"ValueError: Location type cannot be identified")

So I believe they are not encripted :) Also for TPEG ARD I found a questioner to the Athoreties where it is writen that they transmit unencripted Datex2-LR data.

With respect to the PPP-RTK-AdV:

Thank you here is the report from the ESA project that implemnted the service: https://navisp.esa.int/project/details/185/show.

Maybe we should split the issue? Thank you again for your support.

Best, Lars

[JvanKatwijk]

Hi Lars,

That is funny, the header encoding (at least the way I understand it) says that the two channels labeled TPEG are encrypted, but then, it is a long time agp that I looked at it. I'll look further to the TPEG handling and see how to decode it

Nice exercise, thanks for the input

Op zo 24 mrt 2024 om 15:19 schreef werwaswarum @.***>:

Hi Jan, I playing around with TPEG reception in this minute :) With respect to the TPEG channels: There should be three TPEG channels TPEG. TPEG_MM in 5C and and TPEG ARD on 10A.

I could decode Version 1 from time to time by using the OpenLR python version: https://openlr-python.readthedocs.io/en/latest/index.html

My code:

import socket import sys import openlr import base64

HOST ="127.0.0.1" # The remote host PORT = 8888 # The same port as used by the server

while(True): print(f"Run") try: with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.connect((HOST, PORT)) data = s.recv(2048*32)

    test= base64.b64encode(data)
    print(openlr.binary_decode(test, is_base64=True))

except NotImplementedError:
    print(f"Version Error")

except ValueError:
    print(f"ValueError: Location type cannot be identified")

So I believe they are not encripted :) Also for TPEG ARD I found a questioner to the Athoreties where it is writen that they transmit unencripted Datex2-LR data.

With respect to the PPP-RTK-AdV:

Thank you here is the report from the ESA project that implemnted the service: https://navisp.esa.int/project/details/185/show.

Maybe we should split the issue? Thank you again for your support.

Best, Lars

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2016824994, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQHUYOH43Q35IFKUE6LYZ3OIVAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHAZDIOJZGQ . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

[JvanKatwijk]

The "client" separares the headers from the bodies of the data. While there are C++ ;ibraries for encoding base64 (and decoding_ there does not seem to be an easy to use OpenLR library so it might be best to use a combination of C++ and Python. C++ for the dispatching the data into the difefrent frametypes and collecin the databodies, using Python for the decoding of the body. I'll look into it

Op zo 24 mrt 2024 om 15:31 schreef jan van katwijk @.***>:

Hi Lars,

That is funny, the header encoding (at least the way I understand it) says that the two channels labeled TPEG are encrypted, but then, it is a long time agp that I looked at it. I'll look further to the TPEG handling and see how to decode it

Nice exercise, thanks for the input

Op zo 24 mrt 2024 om 15:19 schreef werwaswarum @.***>:

Hi Jan, I playing around with TPEG reception in this minute :) With respect to the TPEG channels: There should be three TPEG channels TPEG. TPEG_MM in 5C and and TPEG ARD on 10A.

I could decode Version 1 from time to time by using the OpenLR python version: https://openlr-python.readthedocs.io/en/latest/index.html

My code:

import socket import sys import openlr import base64

HOST ="127.0.0.1" # The remote host PORT = 8888 # The same port as used by the server

while(True): print(f"Run") try: with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.connect((HOST, PORT)) data = s.recv(2048*32)

    test= base64.b64encode(data)
    print(openlr.binary_decode(test, is_base64=True))

except NotImplementedError:
    print(f"Version Error")

except ValueError:
    print(f"ValueError: Location type cannot be identified")

So I believe they are not encripted :) Also for TPEG ARD I found a questioner to the Athoreties where it is writen that they transmit unencripted Datex2-LR data.

With respect to the PPP-RTK-AdV:

Thank you here is the report from the ESA project that implemnted the service: https://navisp.esa.int/project/details/185/show.

Maybe we should split the issue? Thank you again for your support.

Best, Lars

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2016824994, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQHUYOH43Q35IFKUE6LYZ3OIVAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHAZDIOJZGQ . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

-- Jan van Katwijk

[werwaswarum]

Hi Jan,

That with the header made me curious!

I used python because it is easy to use for first tests, as I don't need to compile every time a change a buffer etc. Sounds like a possible implementation, however the python implementation does not decode all messages, the full implementation is only available in java, see https://github.com/tomtom-international/openlr

I gutes it would be nice to be able to show the data on a map, here an example that uses QGIS: https://github.com/FraunhoferIVI/openlr.git

In this way you/we don't need to implement all things new.

Let me know if I can support the development.

Best regards, Lars

[JvanKatwijk]

OK, the C++ implementation separated the ehaders from the bodies of the frames and stores the bodies in a vect It seems easiest to pass such vectors to a pythin method and see what is coming

As said, I am a little rusty on Python, so I'll have to experiment a little to pass the framedata, but let us see what the results are Come back to you when I refreshed my Python knowledge

Op zo 24 mrt 2024 om 18:31 schreef werwaswarum @.***>:

Hi Jan,

That with the header made me curious!

I used python because it is easy to use for first tests, as I don't need to compile every time a change a buffer etc. Sounds like a possible implementation, however the python implementation does not decode all messages, the full implementation is only available in java, see https://github.com/tomtom-international/openlr

I gutes it would be nice to be able to show the data on a map, here an example that uses QGIS: https://github.com/FraunhoferIVI/openlr.git

In this way you/we don't need to implement all things new.

Let me know if I can support the development.

Best regards, Lars

— Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/320#issuecomment-2016880099, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQGHMT6TS4FNRIACFZLYZ4EYXAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHA4DAMBZHE . You are receiving this because you commented.Message ID: @.***>

-- Jan van Katwijk

[werwaswarum]

Hi Jan, seems good to me. Do you also have an idea, how I can continue with the RTL-PPP-AvD channel?

Best Lars