-
Notifications
You must be signed in to change notification settings - Fork 61
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
Record ETI #296
Comments
I recorded a few minutes of a local ensemble and - played it without any
problem on an eti interpreter, so that does not
give help in interpreting.
Does the resulting eti file play with e.g. dablin?
Op wo 9 aug 2023 om 00:47 schreef awingender ***@***.***>:
… I have been attempting to record an ETI file of live DAB+ transmissions
using QT-DAB 5.3.
I am able to see that an ETI file is generated, however when I attempt to
decode or transmit it, I receive errors about missing FIC information.
Specifically, I am using DABMOD from Open Digital Radio to broadcast ETI
files, but believe the error to be with QT-DAB.
I get the following error from dabmod: "Exception Caught: FIC must be
present to modulate!"
I have 2 devices with same results (HackRF and RTL-SDR). Both devices are
able to scan, receive, and decode the live DAB+ signal.
Currently using Windows 10.
—
Reply to this email directly, view it on GitHub
<#296>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQEPX7JDQMA7ZYAQATDXUK6XBANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Jan van Katwijk
|
Can you play that file in What about re-transmit it with Tried to load it into https://www.basicmaster.de/xpadxpert/ https://github.com/opendigitalradio/dablin https://github.com/Opendigitalradio/ODR-DabMux Honesty I have rarely tried that function, because I am creating eti files with |
No. I get the following error from Dablin when I play my recorded QT-DAB eti files. This error repeats for each frame: I have also tested using pre-recorded sample ETI files from WorldDAB org that do play correctly directly from Dablin.
No. I cannot retransmit the ETI files that I have made using QT-DAB. I get this error: If I use my pre-recorded ETI files from WorldDAB, I am able to successfully transmit using odr-dabmod, and correctly receive DAB radio signal on multiple test radios.
XPADxpert gives error when QT-DAB made ETI file is loaded: My WorldDAB pre-recorded ETI files, loaded into XPADxpert work as expected. This is a nice tool. **Although sometimes it gets stuck at 'extracting all sub-channels' and XPADxpert has to be restarted.
Before today, I had not used eti-tools (eti-cmdline). I was able to easily get it up and running, pipping my output to dablin_gtk. Doing this, my live DAB+ transmission fully worked from Dablin_gtk. How do I use eti-cmdline to record an ETI file? I tried pipping the output of eti-cmdline directly to a test.eti file, and that did not seem to work. I have uploaded two ETI files that I recorded using QT-DAB 5.3. The each 60 second recording was started after I felt the DAB+ signal was correctly being received by QT-DAB. https://www.filebig.net/files/ViYNe5mRKx I do have one thought that may be of concern, but hopefully not! My concern is that I am using a seperate PC to then record an ETI file using QT-DAB. (Using a RTLSDR). Should I be able to record a re-transmission? QT-DAB is able to play it no problem, just issue with recording ETI. |
I have the impression that the problem is caused by a problem in decoding
the FIC by Qt-DAB. Actually I do not know what to do if Qt-DAB rejects the
FIC blocks of a frame.
That is may be a shortcoming of Qt-DAB.
Interesting to read that working with et-cmdline worked fine: the code for
eti-cmdline is the basis for the eti generation in Qt-DAB, the difference
being that FIC/FIB handling in Qt-DAB
is a superset of that in eti-cmdline.
Any suggestion of how to deal with eiti output for frames with an incorrect
FIC is welcome
Op wo 9 aug 2023 om 21:56 schreef awingender ***@***.***>:
… Does the resulting eti file play with e.g. dablin?
No. I get the following error from Dablin when I play my recorded QT-DAB
eti files. This error repeats for each frame:
"ETIPlayer: ignored ETI frame due to wrong (MST) CRC"
I have also tested using pre-recorded sample ETI files from WorldDAB org
that do play correctly directly from Dablin.
What about re-transmit it with odr-dabmod?
No. I cannot retransmit the ETI files that I have made using QT-DAB. I get
this error:
"Exception Caught: FIC must be present to modulate!"
If I use my pre-recorded ETI files from WorldDAB, I am able to
successfully transmit using odr-dabmod, and correctly receive DAB radio
signal on multiple test radios.
Tried to load it into XPADxpert?
XPADxpert gives error when QT-DAB made ETI file is loaded:
"Runtime exception: Wrong FSYNC at frame # 1"
My WorldDAB pre-recorded ETI files, loaded into XPADxpert work as
expected. This is a nice tool. **Although sometimes it gets stuck at
'extracting all sub-channels' and XPADxpert has to be restarted.
Honesty I have rarely tried that function, because I am creating eti files
with eti-cmdline
Before today, I had not used eti-tools (eti-cmdline). I was able to easily
get it up and running, pipping my output to dablin_gtk. Doing this, my live
DAB+ transmission fully worked from Dablin_gtk. How do I use eti-cmdline to
record an ETI file? I tried pipping the output of eti-cmdline directly to a
test.eti file, and that did not seem to work.
------------------------------
I have uploaded two ETI files that I recorded using QT-DAB 5.3. The each
60 second recording was started after I felt the DAB+ signal was correctly
being received by QT-DAB.
https://www.filebig.net/files/ViYNe5mRKx
------------------------------
I do have one thought that may be of concern, but hopefully not!
I am located in the USA. Because of this, I am transmitting my own DAB+
signal using a HackRF and Raspberry Pi, using the working WorldDAB ETI
files. This works 100%.
My concern is that I am using a seperate PC to then record an ETI file
using QT-DAB. (Using a RTLSDR). Should I be able to record a
re-transmission? QT-DAB is able to play it no problem, just issue with
recording ETI.
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQAJ77YQSQPY4L3EWRTXUPTOHANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
Hi, |
I Might have found something, it seems that the "fibValid" flag is always
set to true in the Qt-DAB version, while in the eti-cmdline version
the setting is derived from the handling of the fic blocks.
It might take a few days before this is handled
Op vr 11 aug 2023 om 00:39 schreef dh5ym ***@***.***>:
… Hi,
i can confirm the above. ETI recordings created with qt-dab generate
messages like
ETIPlayer: ignored ETI frame due to wrong (MST) CRC
EnsembleSource: skipping 14 bytes for sync
in dablin. Recordings done with eti-cmdline can be decoded.
I guess still storing the faulty FIC blocks might be the choice.
regards
Mario
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQCTO2RYLUHLJHU6PVLXUVPLVANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
Well, I made a quick change in the software, i.e. passing on data on the
correctness of the fics to the part that generated eti.
My question is: do you use windows, or do you build your own executable or
do you use an AppImage?
Op vr 11 aug 2023 om 14:43 schreef jan van katwijk ***@***.***>:
… I Might have found something, it seems that the "fibValid" flag is always
set to true in the Qt-DAB version, while in the eti-cmdline version
the setting is derived from the handling of the fic blocks.
It might take a few days before this is handled
Op vr 11 aug 2023 om 00:39 schreef dh5ym ***@***.***>:
> Hi,
> i can confirm the above. ETI recordings created with qt-dab generate
> messages like
> ETIPlayer: ignored ETI frame due to wrong (MST) CRC
> EnsembleSource: skipping 14 bytes for sync
> in dablin. Recordings done with eti-cmdline can be decoded.
> I guess still storing the faulty FIC blocks might be the choice.
> regards
> Mario
>
> —
> Reply to this email directly, view it on GitHub
> <#296 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACCPHQCTO2RYLUHLJHU6PVLXUVPLVANCNFSM6AAAAAA3JEXP3Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
--
Jan van Katwijk
--
Jan van Katwijk
|
The friend who supplied me with the recordings was using Windows.
I can only compile on Linux or use Windows on my work PC.
JvanKatwijk ***@***.***> schrieb am Fr., 11. Aug. 2023, 16:08:
… Well, I made a quick change in the software, i.e. passing on data on the
correctness of the fics to the part that generated eti.
My question is: do you use windows, or do you build your own executable or
do you use an AppImage?
Op vr 11 aug 2023 om 14:43 schreef jan van katwijk ***@***.***>:
> I Might have found something, it seems that the "fibValid" flag is
always
> set to true in the Qt-DAB version, while in the eti-cmdline version
> the setting is derived from the handling of the fic blocks.
> It might take a few days before this is handled
>
> Op vr 11 aug 2023 om 00:39 schreef dh5ym ***@***.***>:
>
>> Hi,
>> i can confirm the above. ETI recordings created with qt-dab generate
>> messages like
>> ETIPlayer: ignored ETI frame due to wrong (MST) CRC
>> EnsembleSource: skipping 14 bytes for sync
>> in dablin. Recordings done with eti-cmdline can be decoded.
>> I guess still storing the faulty FIC blocks might be the choice.
>> regards
>> Mario
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <
#296 (comment)>,
>> or unsubscribe
>> <
https://github.com/notifications/unsubscribe-auth/ACCPHQCTO2RYLUHLJHU6PVLXUVPLVANCNFSM6AAAAAA3JEXP3Q>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
>
> --
> Jan van Katwijk
>
>
>
>
--
Jan van Katwijk
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOINJVAB2PBBDO3FRNU6IGLXUY4HJANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I uploaded a Windows version, with "-test" added to the name, that contains
a few mods, telling the eti-generator the state of the FIC blocks
Op vr 11 aug 2023 om 16:36 schreef dh5ym ***@***.***>:
… The friend who supplied me with the recordings was using Windows.
I can only compile on Linux or use Windows on my work PC.
JvanKatwijk ***@***.***> schrieb am Fr., 11. Aug. 2023, 16:08:
> Well, I made a quick change in the software, i.e. passing on data on the
> correctness of the fics to the part that generated eti.
> My question is: do you use windows, or do you build your own executable
or
> do you use an AppImage?
>
>
> Op vr 11 aug 2023 om 14:43 schreef jan van katwijk ***@***.***>:
>
> > I Might have found something, it seems that the "fibValid" flag is
> always
> > set to true in the Qt-DAB version, while in the eti-cmdline version
> > the setting is derived from the handling of the fic blocks.
> > It might take a few days before this is handled
> >
> > Op vr 11 aug 2023 om 00:39 schreef dh5ym ***@***.***>:
> >
> >> Hi,
> >> i can confirm the above. ETI recordings created with qt-dab generate
> >> messages like
> >> ETIPlayer: ignored ETI frame due to wrong (MST) CRC
> >> EnsembleSource: skipping 14 bytes for sync
> >> in dablin. Recordings done with eti-cmdline can be decoded.
> >> I guess still storing the faulty FIC blocks might be the choice.
> >> regards
> >> Mario
> >>
> >> —
> >> Reply to this email directly, view it on GitHub
> >> <
> #296 (comment)>,
>
> >> or unsubscribe
> >> <
>
https://github.com/notifications/unsubscribe-auth/ACCPHQCTO2RYLUHLJHU6PVLXUVPLVANCNFSM6AAAAAA3JEXP3Q>
>
> >> .
> >> You are receiving this because you commented.Message ID:
> >> ***@***.***>
> >>
> >
> >
> > --
> > Jan van Katwijk
> >
> >
> >
> >
>
> --
> Jan van Katwijk
>
> —
> Reply to this email directly, view it on GitHub
> <
#296 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AOINJVAB2PBBDO3FRNU6IGLXUY4HJANCNFSM6AAAAAA3JEXP3Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQENI5RKDPK5UPNNLO3XUY7OPANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
I just tested setup-qt-dab32-5.4-test.exe and unfortunately received the same FSYNC errors from xpadxpert.
For my use case, Windows is the most helpful. Just a follow-up of a previous question I had above: |
Just for my understanding: the result of processing with eti-cmdline does
not seem to contain an error, while the result of processing with Qt-DAB
gives an error?
If so, then I have to compare more closely the differences between the
processing part in the two programs
Op vr 11 aug 2023 om 20:48 schreef awingender ***@***.***>:
… I uploaded a Windows version, with "-test" added to the name, that contains
a few mods, telling the eti-generator the state of the FIC blocks
I just tested setup-qt-dab32-5.4-test.exe
<https://github.com/JvanKatwijk/qt-dab/releases/download/qt-dab-4.7%2F5.4/setup-qt-dab32-5.4-test.exe>
and unfortunately received the same FSYNC errors from xpadxpert.
"Runtime Exception: Wrong FSYNC at frame # 1"
My question is: do you use windows, or do you build your own executable or
do you use an AppImage?
For my use case, Windows is the most helpful.
Just a follow-up of a previous question I had above:
I have since been successfully in getting eti-cmdline to output a working
ETI file of my DAB 're-broadcast'.
"eti-cmdline-rtlsdr -C 7A -G 20.7 > dump.eti"
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQGUT2RMKLQSFT7VTYDXUZ47NANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
Hi,
maybe its a problem specific to the Windows version. I just tried with the
64bit Appimage version and 5 different ensembles. Each of the recordings
(even the one with bad SNR) was playing fine with dablin.
I cannot test with the windows version myself.
regards
Mario
Am Fr., 11. Aug. 2023 um 22:09 Uhr schrieb JvanKatwijk <
***@***.***>:
… Just for my understanding: the result of processing with eti-cmdline does
not seem to contain an error, while the result of processing with Qt-DAB
gives an error?
If so, then I have to compare more closely the differences between the
processing part in the two programs
Op vr 11 aug 2023 om 20:48 schreef awingender ***@***.***>:
> I uploaded a Windows version, with "-test" added to the name, that
contains
> a few mods, telling the eti-generator the state of the FIC blocks
>
> I just tested setup-qt-dab32-5.4-test.exe
> <
https://github.com/JvanKatwijk/qt-dab/releases/download/qt-dab-4.7%2F5.4/setup-qt-dab32-5.4-test.exe>
> and unfortunately received the same FSYNC errors from xpadxpert.
> "Runtime Exception: Wrong FSYNC at frame # 1"
>
> My question is: do you use windows, or do you build your own executable
or
> do you use an AppImage?
>
> For my use case, Windows is the most helpful.
>
> Just a follow-up of a previous question I had above:
> I have since been successfully in getting eti-cmdline to output a
working
> ETI file of my DAB 're-broadcast'.
> "eti-cmdline-rtlsdr -C 7A -G 20.7 > dump.eti"
>
> —
> Reply to this email directly, view it on GitHub
> <
#296 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ACCPHQGUT2RMKLQSFT7VTYDXUZ47NANCNFSM6AAAAAA3JEXP3Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
--
Jan van Katwijk
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOINJVALD4ZPAPOU4WCTZ4TXU2GO5ANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yes, but my testing of QT-DAB has been exclusively on Windows10. I will try the Appimage version of QT-DAB on RPi and report back |
I do not know and I do not understand
The relevant code for telling the ETI stream the status of the FIC block
i.e. true, or false, is now the same for Qt-DAB and eti-cmdline
(as made available in the Window version. (a flag is set to true if the crc
check for the fic block succeeds and to false otherwise.)
Op vr 11 aug 2023 om 23:38 schreef dh5ym ***@***.***>:
… Hi,
maybe its a problem specific to the Windows version. I just tried with the
64bit Appimage version and 5 different ensembles. Each of the recordings
(even the one with bad SNR) was playing fine with dablin.
I cannot test with the windows version myself.
regards
Mario
Am Fr., 11. Aug. 2023 um 22:09 Uhr schrieb JvanKatwijk <
***@***.***>:
> Just for my understanding: the result of processing with eti-cmdline
does
> not seem to contain an error, while the result of processing with Qt-DAB
> gives an error?
> If so, then I have to compare more closely the differences between the
> processing part in the two programs
>
>
> Op vr 11 aug 2023 om 20:48 schreef awingender ***@***.***>:
>
> > I uploaded a Windows version, with "-test" added to the name, that
> contains
> > a few mods, telling the eti-generator the state of the FIC blocks
> >
> > I just tested setup-qt-dab32-5.4-test.exe
> > <
>
https://github.com/JvanKatwijk/qt-dab/releases/download/qt-dab-4.7%2F5.4/setup-qt-dab32-5.4-test.exe>
>
> > and unfortunately received the same FSYNC errors from xpadxpert.
> > "Runtime Exception: Wrong FSYNC at frame # 1"
> >
> > My question is: do you use windows, or do you build your own
executable
> or
> > do you use an AppImage?
> >
> > For my use case, Windows is the most helpful.
> >
> > Just a follow-up of a previous question I had above:
> > I have since been successfully in getting eti-cmdline to output a
> working
> > ETI file of my DAB 're-broadcast'.
> > "eti-cmdline-rtlsdr -C 7A -G 20.7 > dump.eti"
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <
> #296 (comment)>,
>
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/ACCPHQGUT2RMKLQSFT7VTYDXUZ47NANCNFSM6AAAAAA3JEXP3Q>
>
> > .
> > You are receiving this because you commented.Message ID:
> > ***@***.***>
> >
>
>
> --
> Jan van Katwijk
>
> —
> Reply to this email directly, view it on GitHub
> <
#296 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AOINJVALD4ZPAPOU4WCTZ4TXU2GO5ANCNFSM6AAAAAA3JEXP3Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQD67Y6AYOLPS7K54VTXU2Q63ANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
I can just have a look into the faulty ETI files with some different analysis tool. Maybe this gives some more insight. The fact that it seems to work under Linux suggests that there is some problem specific to the Windows compilation. No clue what this could be. |
That would be helpful, since iff the eti-cmdline output is OK and the
Qt-DAB output is not OK, then I am really puzzled since the
processing is (almost) identical
Op za 12 aug 2023 om 21:44 schreef dh5ym ***@***.***>:
… I can just have a look into the faulty ETI files with some different
analysis tool. Maybe this gives some more insight. The fact that it seems
to work under Linux suggests that there is some problem specific to the
Windows compilation. No clue what this could be.
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQHFKCMNC7VBJKXLD33XU7MJXANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
I agree that the problem seems to be Windows specific. I next used ETIsnoop from OpenDigitalRadio. https://imgur.com/a/1WRP57k For a good ETI file: After EOF, i see the CRC shows "Value: No Error" For a good ETI file: FYSYNC shows "Value: OK" |
I might have found something: I did not specify the output file to be
written as a binary file.
I uploaded a version (regular 5.4) wihere the file is explcitly opened as a
file for binary output
Op ma 14 aug 2023 om 23:37 schreef awingender ***@***.***>:
… The fact that it seems to work under Linux suggests that there is some
problem specific to the Windows compilation
I agree that the problem seems to be Windows specific.
I tested recording ETI file with QT-DAB 5.3 & 5.4 in linux, and the
resulting ETI file works correctly.
I next used ETIsnoop <https://github.com/Opendigitalradio/etisnoop> from
OpenDigitalRadio.
From what I'm seeing. FSYNC and CRC are correct at the beginning of
FRAME#0, but by FRAME#1, both FSYNC and CRC are wrong.
https://imgur.com/a/1WRP57k
See image above. I compared the output of ETISnoop of a known good vs bad
ETI file.
For a good ETI file: I see that all TPLs say EEP "Equal Error Protection"
For a bad ETI file: I see that some TPLs say UEP "Unequal Error Protection"
For a good ETI file: After EOF, i see the CRC shows "Value: No Error"
For a bad ETI file: After EOF, i see the CRC shows "Value: Mismatch: 2da8"
For a good ETI file: FYSYNC shows "Value: OK"
For a bad ETI file: FYSNC shows "Value: Wrong FYSNC"
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQE7V3FROODDUNU322DXVKLBPANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jan van Katwijk
|
It seems this did the job. With the 5.4 Windows binary i was able to record a ETI from DR Deutschland and read it into other tooling. |
That works!!! I tested recording an ETI file using latest QT-DAB 5.4 on Windows 10. I want to thank both of you for your help. Your work has and will continue to indirectly/directly help many many people get a better DAB experience in the future. The ability to record an ETI from Windows, using a low-cost RTLSDR will help many people I work with troubleshoot radio issues we are investigating far from our offices. Again, thank you for this great tool. |
Feel free to ask if you have further questions about qt-dab
…On Tue, Aug 15, 2023, 9:00 PM awingender ***@***.***> wrote:
Closed #296 <#296> as
completed.
—
Reply to this email directly, view it on GitHub
<#296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQFQKKDYZMTCG4OYJZDXVPBNPANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Is it possible that an image/artwork could be received by multiple vehicle radios, but not stored in the recorded ETI? My scenario. I had someone in South UK record an ETI for me this morning using QT-DAB 5.4. I received the file of the BBC Ensemble, but it does not show any image data at all when inspected with XPADxpert. When I myself try to transmit the ETI file, it works completely, except I see no image/artwork from my radio. So to me, it seems the image data was not recorded by QT-DAB. The person recording ETI confirmed they could see images on 2 test radios at same time as recording. Radios are only DAB, not IP/internet connected at all. Forgive me if this goes outside the scope of QT-DAB. Test File recorded today: |
I would assume that QT-DAB only supports XPAD MOT. SPI is very unlikely. But its possible that something is not assembled in the way it should be. I have not enough knowledge about the details of ETI to judge that but would not assume that PAD data is lost during recording. If i have enough time i can try to look into the file with some tooling tomorrow and watch out for errors. |
After a brief look into the ensemble i think its not an issue of the eti recording. |
The way an ETI file is generated is different from regular DAB processing.
The FIC part is directly derviced from the FIC input, for the payload the
list of subchannels - the description is obviously derived from the FIC
input - is walked through and for each subchannel the
deconvolution is applied as given.
No correction is made - again, in the process of ETI file generation - of
mapping subchannels to services or whatsoever.
So, the obvious question is: how is the data transmitted, as separate
service or embedded as MOT in OAD data
Op vr 18 aug 2023 om 10:28 schreef dh5ym ***@***.***>:
… After a brief look into the ensemble i think its not an issue of the eti
recording.
The ensemble BBC National DAB contains some DAB services with dynamic
label but it seems the xpad does not contain any MOT. Instead there is a
data service "BBC Guide" which contains EPG and MOT in enhanced packet
mode. I doubt qt-dab can support that. Some of the car radios might already
use information from such data services to display station logos e.g. If
you need more info drop me a line to mario.dh5ym@ gmail.com
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQH3L5AD245NSYLNUQDXV4RTBANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Jan van Katwijk
|
I think @dh5ym is correct or very close It appears that the artwork is not being transmitted using the traditional MOT method within the XPAD. Instead, the BBC National DAB ensemble seems to be transmitting a data service called "BBC Guide, Service ID: E1C79E5E." which contains both EPG (aka SPI) and the MOT data.
It appears that the images are part of a separate data service rather than being embedded within the XPAD as MOT data. This might explain that the absence of image data in the ETI file. From WorldDAB, I have a known-good ETI file from Germany with similar SPI type images. |
I have limited experience with the EPG handling. The NPO (dutch radio and
TV) just sends empty stuff.
If and EPG service is part of the ensemble, it sends it content using a
subchannel. As said, the content of each of the subchannels (is just fed to
the ETI processor - it does the
deconvoluton - and then added - in the right place into the ETI file.
As far as I can see, there is not further processing or interpretation,
only deconvolution, so it seems to me that if such a service is part of the
input,
its payload should end up in the ETI file.
Another thing is that in the "normal" EPG processing as done by Qt-DAB
there is no SPI specific processing, basically because - as I said above -
the
NPO does not give me that.
I would appreciate getting a recording from an ensemble with an EPG channel
containing SPI data, that would help me im proving QT-DAB
best
jan
Op vr 18 aug 2023 om 21:21 schreef awingender ***@***.***>:
… I think @dh5ym <https://github.com/dh5ym> is correct or very close
It appears that the artwork is not being transmitted using the traditional
MOT method within the XPAD. Instead, the BBC National DAB ensemble
<https://en.wikipedia.org/wiki/BBC_National_DAB> seems to be transmitting
a data service called "BBC Guide, Service ID: E1C79E5E." which contains
both EPG (aka SPI
<https://www.worlddab.org/dab/data-applications/service-and-programme-information>)
and the MOT data.
https://imgur.com/a/0RfnmzN
So, the obvious question is: how is the data transmitted, as separate
service or embedded as MOT in OAD data
It appears that the images are part of a separate data service rather than
being embedded within the XPAD as MOT data. This might explain that the
absence of image data in the ETI file.
From WorldDAB, I have a known-good ETI file from Germany with similar SPI
type images.
When I test broadcasting the German ETI file, QT-DAB was able to display
the images OK. (The BBC images do not show in QT-DAB)
I next recorded an ETI of this SPI broadcast, and rebroadcasted that ETI
itself again. Images recorded and played correctly again.
So it seems QT-DAB can work
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQEQOUA3JREZM5DF5NTXV66DLANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Jan van Katwijk
|
Here is the German ETI file that I have. It was not recorded in QT-DAB from what I can tell, but seems to contain SPI data, as well as traditional MOT. When broadcasted, the images in this ETI file do work with QT-DAB, unlike the ETI file from UK. This file appears to contain 5 subchannels of tdc & mot data: |
Thanks
Right now I am traveling for a couple of weeks, will pick this subject up
on return
Op ma 21 aug 2023 om 17:58 schreef awingender ***@***.***>:
… Here is the German ETI file that I have. It was not recorded in QT-DAB
from what I can tell, but seems to contain SPI data, as well as traditional
MOT. When broadcasted, the images in this ETI file do work with QT-DAB,
unlike the ETI file from UK.
http://www.filebig.net/files/sR4tyVgP46
This file appears to contain 5 subchannels of tdc & mot data:
Content Details
<https://github.com/JvanKatwijk/qt-dab/assets/67070189/a770030a-4fa8-4b07-b6d0-c1c4542e7ded>
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCPHQBR4JCAHDJ73IY5MXLXWOASLANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Jan van Katwijk
|
In Germany almost all ensembles use MOT/SLS via XPAD. Some SPI tests with
dedicated data services emerge the recent years but as far as i know are
mainly used to transfer station logos (also for stations outside the
ensemble e.g. FM stations).
Am Mi., 23. Aug. 2023 um 08:37 Uhr schrieb JvanKatwijk <
***@***.***>:
… Thanks
Right now I am traveling for a couple of weeks, will pick this subject up
on return
Op ma 21 aug 2023 om 17:58 schreef awingender ***@***.***>:
> Here is the German ETI file that I have. It was not recorded in QT-DAB
> from what I can tell, but seems to contain SPI data, as well as
traditional
> MOT. When broadcasted, the images in this ETI file do work with QT-DAB,
> unlike the ETI file from UK.
> http://www.filebig.net/files/sR4tyVgP46
>
> This file appears to contain 5 subchannels of tdc & mot data:
> Content Details
> <
https://github.com/JvanKatwijk/qt-dab/assets/67070189/a770030a-4fa8-4b07-b6d0-c1c4542e7ded>
>
> —
> Reply to this email directly, view it on GitHub
> <
#296 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ACCPHQBR4JCAHDJ73IY5MXLXWOASLANCNFSM6AAAAAA3JEXP3Q>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
Jan van Katwijk
—
Reply to this email directly, view it on GitHub
<#296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOINJVBXAZHTKSAWMVSJS2LXWWQKFANCNFSM6AAAAAA3JEXP3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have been attempting to record an ETI file of live DAB+ transmissions using QT-DAB 5.3.
I am able to see that an ETI file is generated, however when I attempt to decode or transmit it, I receive errors about missing FIC information.
Specifically, I am using DABMOD from Open Digital Radio to broadcast ETI files, but believe the error to be with QT-DAB. ETI files that I did NOT create with QT-DAB 5.3 work correctly. I get the following error from dabmod: "Exception Caught: FIC must be present to modulate!"
I have 2 devices with same results (HackRF and RTL-SDR). Both devices are able to scan, receive, and decode the live DAB+ signal.
Currently using Windows 10.
The text was updated successfully, but these errors were encountered: