Buildin Server not comming up #320

werwaswarum · 2024-03-20T22:57:31Z

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 · 2024-03-21T12:55:14Z

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 <#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 · 2024-03-21T16:28:27Z

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 · 2024-03-21T16:45:35Z

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 <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQFNN6VVTQ4GFEZCRNLYZMDEBAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJSHA4TKNRXGE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

JvanKatwijk · 2024-03-21T16:54:53Z

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 > <#320 (comment)>, > 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 · 2024-03-21T22:47:48Z

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 · 2024-03-23T12:47:37Z

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 <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQFRKFSXFJUJPCUQJBTYZNPSTAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJTHE4DAOBZGI> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

werwaswarum · 2024-03-23T20:20:18Z

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 · 2024-03-24T13:05:15Z

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 <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQDMYJ22NYTOC7OQO6LYZXPZPAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGU4TGMZUGM> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

JvanKatwijk · 2024-03-24T13:24:52Z

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 > <#320 (comment)>, > 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 · 2024-03-24T14:19:32Z

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 · 2024-03-24T14:31:48Z

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 <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQHUYOH43Q35IFKUE6LYZ3OIVAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHAZDIOJZGQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

JvanKatwijk · 2024-03-24T15:38:39Z

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 > <#320 (comment)>, > 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 · 2024-03-24T17:31:34Z

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 · 2024-03-25T13:24:32Z

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 <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCPHQGHMT6TS4FNRIACFZLYZ4EYXAVCNFSM6AAAAABFAMESE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHA4DAMBZHE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jan van Katwijk

werwaswarum · 2024-03-25T14:37:01Z

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

Best Lars

werwaswarum changed the title ~~Buidl in Server not comming up~~ Buildin Server not comming up Mar 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Buildin Server not comming up #320

Buildin Server not comming up #320

werwaswarum commented Mar 20, 2024

JvanKatwijk commented Mar 21, 2024 via email

werwaswarum commented Mar 21, 2024

JvanKatwijk commented Mar 21, 2024 via email

JvanKatwijk commented Mar 21, 2024 via email

werwaswarum commented Mar 21, 2024

JvanKatwijk commented Mar 23, 2024 via email

werwaswarum commented Mar 23, 2024

JvanKatwijk commented Mar 24, 2024 via email

JvanKatwijk commented Mar 24, 2024 via email

werwaswarum commented Mar 24, 2024

JvanKatwijk commented Mar 24, 2024 via email

JvanKatwijk commented Mar 24, 2024 via email

werwaswarum commented Mar 24, 2024

JvanKatwijk commented Mar 25, 2024 via email

werwaswarum commented Mar 25, 2024

Buildin Server not comming up #320

Buildin Server not comming up #320

Comments

werwaswarum commented Mar 20, 2024

JvanKatwijk commented Mar 21, 2024 via email

werwaswarum commented Mar 21, 2024

JvanKatwijk commented Mar 21, 2024 via email

JvanKatwijk commented Mar 21, 2024 via email

werwaswarum commented Mar 21, 2024

JvanKatwijk commented Mar 23, 2024 via email

werwaswarum commented Mar 23, 2024

JvanKatwijk commented Mar 24, 2024 via email

JvanKatwijk commented Mar 24, 2024 via email

werwaswarum commented Mar 24, 2024

JvanKatwijk commented Mar 24, 2024 via email

JvanKatwijk commented Mar 24, 2024 via email

werwaswarum commented Mar 24, 2024

JvanKatwijk commented Mar 25, 2024 via email

werwaswarum commented Mar 25, 2024