-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buildin Server not comming up #320
Comments
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
|
Hi Jan, Thank you for your help, although my issue was very confused. With the included TPEG client I see now data on the TPEG channels and can receive data on the socket, nice! 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 Unfortunately no port show up. Qt-DAB-DR Deutschland -5C-Do--März-21-16-58-43-2024.zip |
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
|
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
|
Hi Jan, Thank you again for your support. I thought there is a huge interest in data services, especially in Germany, where cellular networks are not available everywhere. |
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
|
Hi Jan, Would it be possible to test my build with these data? Looking forward to seeing where we can go on. Best, |
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
|
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
|
Hi Jan, 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:
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? Best, |
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
|
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
|
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. I gutes it would be nice to be able to show the data on a map, here an example that uses QGIS: In this way you/we don't need to implement all things new. Let me know if I can support the development. Best regards, |
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
|
Hi Jan, Best Lars |
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
The text was updated successfully, but these errors were encountered: