Dynamic Label method not quite right #14
Comments
|
Thanks for the info. I'll have a look this afternoon
2017-08-20 23:54 GMT+02:00 nottledim <notifications@github.com>:
… For some reason I don't receive any DL messages. However the dataOut
callback does print some garbage characters. So I was looking at the code
and I think there's a misunderstnding. Either mine or yours :-) I can only
find a spec for DL+ so I'm not sure.
Referring to padHandler::dynamicLabel method in pad-handler.cpp
So far as I can tell the DL command field comprises one byte header and
field_1 message bytes. This is why field_1 is specified as one less than DL
Command length.
This makes the header length 3 byes not 2 bytes and affects dataLength
calculation and the start byte of the message, which should be data[3] not
data[2].
Changing this removes the garbage data problem I was seeing but as I
receive no real messages I can't test it any further.
c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
01.01.01_60/ts_102980v010101p.pdf
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#14>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwBoq3q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
carried as a DL command so CFlag is 1 whereas your code is for Cflag =0.
It begs the question why I'm receiving garbage characters.
Thanks
Dick
…On 21 August 2017 08:13:27 JvanKatwijk ***@***.***> wrote:
Thanks for the info. I'll have a look this afternoon
2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
> For some reason I don't receive any DL messages. However the dataOut
> callback does print some garbage characters. So I was looking at the code
> and I think there's a misunderstnding. Either mine or yours :-) I can only
> find a spec for DL+ so I'm not sure.
>
> Referring to padHandler::dynamicLabel method in pad-handler.cpp
> So far as I can tell the DL command field comprises one byte header and
> field_1 message bytes. This is why field_1 is specified as one less than DL
> Command length.
>
> This makes the header length 3 byes not 2 bytes and affects dataLength
> calculation and the start byte of the message, which should be data[3] not
> data[2].
>
> Changing this removes the garbage data problem I was seeing but as I
> receive no real messages I can't test it any further.
>
> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
> 01.01.01_60/ts_102980v010101p.pdf
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#14>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AITzwBoq3q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
> .
>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#14 (comment)
|
|
What might be the case is that the test on the CFlag is ONLY done for the
first segment, it seems that for successor segments
no C flag is tested. Since I never was confronted with a Cflag 1 that did
not harm apparently.
Looking at the code, it seems that whenever the C flag is on, the behaviour
is undefined and depends (a.o) on the value of moreXpad
To me it seems that an explicit check on the CFlag is needed.
best
jan
2017-08-21 11:07 GMT+02:00 nottledim <notifications@github.com>:
… Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
carried as a DL command so CFlag is 1 whereas your code is for Cflag =0.
It begs the question why I'm receiving garbage characters.
Thanks
Dick
On 21 August 2017 08:13:27 JvanKatwijk ***@***.***> wrote:
> Thanks for the info. I'll have a look this afternoon
>
>
> 2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
>
>> For some reason I don't receive any DL messages. However the dataOut
>> callback does print some garbage characters. So I was looking at the
code
>> and I think there's a misunderstnding. Either mine or yours :-) I can
only
>> find a spec for DL+ so I'm not sure.
>>
>> Referring to padHandler::dynamicLabel method in pad-handler.cpp
>> So far as I can tell the DL command field comprises one byte header and
>> field_1 message bytes. This is why field_1 is specified as one less
than DL
>> Command length.
>>
>> This makes the header length 3 byes not 2 bytes and affects dataLength
>> calculation and the start byte of the message, which should be data[3]
not
>> data[2].
>>
>> Changing this removes the garbage data problem I was seeing but as I
>> receive no real messages I can't test it any further.
>>
>> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
>> 01.01.01_60/ts_102980v010101p.pdf
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> <#14>, or mute the
thread
>> <https://github.com/notifications/unsubscribe-auth/
AITzwBoq3q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
>> .
>>
>
>
>
> --
> Jan van Katwijk
>
>
> +31 (0)15 3698980 <+31%2015%20369%208980>
> +31 (0) 628260355 <+31%206%2028260355>
>
>
> --
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
> #14 (comment)-
323664633
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwGDc8Zd_qzxzwhQzENmPO1xKAjW0ks5saUjHgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Forget the previous mail. I have to look into what I have written down
there (just cannot follow it anymore)
j
2017-08-21 14:04 GMT+02:00 jan van katwijk <j.vankatwijk@gmail.com>:
… What might be the case is that the test on the CFlag is ONLY done for the
first segment, it seems that for successor segments
no C flag is tested. Since I never was confronted with a Cflag 1 that did
not harm apparently.
Looking at the code, it seems that whenever the C flag is on, the
behaviour is undefined and depends (a.o) on the value of moreXpad
To me it seems that an explicit check on the CFlag is needed.
best
jan
2017-08-21 11:07 GMT+02:00 nottledim ***@***.***>:
> Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
> carried as a DL command so CFlag is 1 whereas your code is for Cflag =0.
>
> It begs the question why I'm receiving garbage characters.
>
> Thanks
>
> Dick
>
>
>
> On 21 August 2017 08:13:27 JvanKatwijk ***@***.***> wrote:
>
> > Thanks for the info. I'll have a look this afternoon
> >
> >
> > 2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
> >
> >> For some reason I don't receive any DL messages. However the dataOut
> >> callback does print some garbage characters. So I was looking at the
> code
> >> and I think there's a misunderstnding. Either mine or yours :-) I can
> only
> >> find a spec for DL+ so I'm not sure.
> >>
> >> Referring to padHandler::dynamicLabel method in pad-handler.cpp
> >> So far as I can tell the DL command field comprises one byte header and
> >> field_1 message bytes. This is why field_1 is specified as one less
> than DL
> >> Command length.
> >>
> >> This makes the header length 3 byes not 2 bytes and affects dataLength
> >> calculation and the start byte of the message, which should be data[3]
> not
> >> data[2].
> >>
> >> Changing this removes the garbage data problem I was seeing but as I
> >> receive no real messages I can't test it any further.
> >>
> >> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
> >> 01.01.01_60/ts_102980v010101p.pdf
> >>
> >> —
> >> You are receiving this because you are subscribed to this thread.
> >> Reply to this email directly, view it on GitHub
> >> <#14>, or mute the
> thread
> >> <https://github.com/notifications/unsubscribe-auth/AITzwBoq3
> q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
> >> .
> >>
> >
> >
> >
> > --
> > Jan van Katwijk
> >
> >
> > +31 (0)15 3698980 <+31%2015%20369%208980>
> > +31 (0) 628260355 <+31%206%2028260355>
> >
> >
> > --
> > You are receiving this because you authored the thread.
> > Reply to this email directly or view it on GitHub:
> > #14#
> issuecomment-323664633
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#14 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AITzwGDc8Zd_qzxzwhQzENmPO1xKAjW0ks5saUjHgaJpZM4O8vcS>
> .
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Interesting problem. Actually I have no clue.
Is it possible for you to record a fragment of raw input data that shows
the problem and send me a link?
Otherwise, pls add some print statements, there are e.g. two occurrences of
showLabel
best
jan
2017-08-21 15:05 GMT+02:00 jan van katwijk <j.vankatwijk@gmail.com>:
… Forget the previous mail. I have to look into what I have written down
there (just cannot follow it anymore)
j
2017-08-21 14:04 GMT+02:00 jan van katwijk ***@***.***>:
> What might be the case is that the test on the CFlag is ONLY done for the
> first segment, it seems that for successor segments
> no C flag is tested. Since I never was confronted with a Cflag 1 that did
> not harm apparently.
>
> Looking at the code, it seems that whenever the C flag is on, the
> behaviour is undefined and depends (a.o) on the value of moreXpad
>
> To me it seems that an explicit check on the CFlag is needed.
> best
> jan
>
>
>
>
> 2017-08-21 11:07 GMT+02:00 nottledim ***@***.***>:
>
>> Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
>> carried as a DL command so CFlag is 1 whereas your code is for Cflag =0.
>>
>> It begs the question why I'm receiving garbage characters.
>>
>> Thanks
>>
>> Dick
>>
>>
>>
>> On 21 August 2017 08:13:27 JvanKatwijk ***@***.***> wrote:
>>
>> > Thanks for the info. I'll have a look this afternoon
>> >
>> >
>> > 2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
>> >
>> >> For some reason I don't receive any DL messages. However the dataOut
>> >> callback does print some garbage characters. So I was looking at the
>> code
>> >> and I think there's a misunderstnding. Either mine or yours :-) I can
>> only
>> >> find a spec for DL+ so I'm not sure.
>> >>
>> >> Referring to padHandler::dynamicLabel method in pad-handler.cpp
>> >> So far as I can tell the DL command field comprises one byte header
>> and
>> >> field_1 message bytes. This is why field_1 is specified as one less
>> than DL
>> >> Command length.
>> >>
>> >> This makes the header length 3 byes not 2 bytes and affects dataLength
>> >> calculation and the start byte of the message, which should be
>> data[3] not
>> >> data[2].
>> >>
>> >> Changing this removes the garbage data problem I was seeing but as I
>> >> receive no real messages I can't test it any further.
>> >>
>> >> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
>> >> 01.01.01_60/ts_102980v010101p.pdf
>> >>
>> >> —
>> >> You are receiving this because you are subscribed to this thread.
>> >> Reply to this email directly, view it on GitHub
>> >> <#14>, or mute the
>> thread
>> >> <https://github.com/notifications/unsubscribe-auth/AITzwBoq3
>> q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
>> >> .
>> >>
>> >
>> >
>> >
>> > --
>> > Jan van Katwijk
>> >
>> >
>> > +31 (0)15 3698980 <+31%2015%20369%208980>
>> > +31 (0) 628260355 <+31%206%2028260355>
>> >
>> >
>> > --
>> > You are receiving this because you authored the thread.
>> > Reply to this email directly or view it on GitHub:
>> > #14 (comment)
>> mment-323664633
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#14 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AITzwGDc8Zd_qzxzwhQzENmPO1xKAjW0ks5saUjHgaJpZM4O8vcS>
>> .
>>
>
>
>
> --
> Jan van Katwijk
>
>
> +31 (0)15 3698980 <+31%2015%20369%208980>
> +31 (0) 628260355 <+31%206%2028260355>
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I can take recordings, but I don't know how. What should I do?
Dick
…On 21 August 2017 19:12:41 JvanKatwijk ***@***.***> wrote:
Interesting problem. Actually I have no clue.
Is it possible for you to record a fragment of raw input data that shows
the problem and send me a link?
Otherwise, pls add some print statements, there are e.g. two occurrences of
showLabel
best
jan
2017-08-21 15:05 GMT+02:00 jan van katwijk ***@***.***>:
> Forget the previous mail. I have to look into what I have written down
> there (just cannot follow it anymore)
> j
>
> 2017-08-21 14:04 GMT+02:00 jan van katwijk ***@***.***>:
>
>> What might be the case is that the test on the CFlag is ONLY done for the
>> first segment, it seems that for successor segments
>> no C flag is tested. Since I never was confronted with a Cflag 1 that did
>> not harm apparently.
>>
>> Looking at the code, it seems that whenever the C flag is on, the
>> behaviour is undefined and depends (a.o) on the value of moreXpad
>>
>> To me it seems that an explicit check on the CFlag is needed.
>> best
>> jan
>>
>>
>>
>>
>> 2017-08-21 11:07 GMT+02:00 nottledim ***@***.***>:
>>
>>> Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
>>> carried as a DL command so CFlag is 1 whereas your code is for Cflag =0.
>>>
>>> It begs the question why I'm receiving garbage characters.
>>>
>>> Thanks
>>>
>>> Dick
>>>
>>>
>>>
>>> On 21 August 2017 08:13:27 JvanKatwijk ***@***.***> wrote:
>>>
>>> > Thanks for the info. I'll have a look this afternoon
>>> >
>>> >
>>> > 2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
>>> >
>>> >> For some reason I don't receive any DL messages. However the dataOut
>>> >> callback does print some garbage characters. So I was looking at the
>>> code
>>> >> and I think there's a misunderstnding. Either mine or yours :-) I can
>>> only
>>> >> find a spec for DL+ so I'm not sure.
>>> >>
>>> >> Referring to padHandler::dynamicLabel method in pad-handler.cpp
>>> >> So far as I can tell the DL command field comprises one byte header
>>> and
>>> >> field_1 message bytes. This is why field_1 is specified as one less
>>> than DL
>>> >> Command length.
>>> >>
>>> >> This makes the header length 3 byes not 2 bytes and affects dataLength
>>> >> calculation and the start byte of the message, which should be
>>> data[3] not
>>> >> data[2].
>>> >>
>>> >> Changing this removes the garbage data problem I was seeing but as I
>>> >> receive no real messages I can't test it any further.
>>> >>
>>> >> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
>>> >> 01.01.01_60/ts_102980v010101p.pdf
>>> >>
>>> >> —
>>> >> You are receiving this because you are subscribed to this thread.
>>> >> Reply to this email directly, view it on GitHub
>>> >> <#14>, or mute the
>>> thread
>>> >> <https://github.com/notifications/unsubscribe-auth/AITzwBoq3
>>> q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
>>> >> .
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Jan van Katwijk
>>> >
>>> >
>>> > +31 (0)15 3698980 <+31%2015%20369%208980>
>>> > +31 (0) 628260355 <+31%206%2028260355>
>>> >
>>> >
>>> > --
>>> > You are receiving this because you authored the thread.
>>> > Reply to this email directly or view it on GitHub:
>>> > #14 (comment)
>>> mment-323664633
>>>
>>> —
>>> You are receiving this because you commented.
>>> Reply to this email directly, view it on GitHub
>>> <#14 (comment)>,
>>> or mute the thread
>>> <https://github.com/notifications/unsubscribe-auth/AITzwGDc8Zd_qzxzwhQzENmPO1xKAjW0ks5saUjHgaJpZM4O8vcS>
>>> .
>>>
>>
>>
>>
>> --
>> Jan van Katwijk
>>
>>
>> +31 (0)15 3698980 <+31%2015%20369%208980>
>> +31 (0) 628260355 <+31%206%2028260355>
>>
>
>
>
> --
> Jan van Katwijk
>
>
> +31 (0)15 3698980 <+31%2015%20369%208980>
> +31 (0) 628260355 <+31%206%2028260355>
>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#14 (comment)
|
|
If you are able to run Qt-DAB, that has a provision to dump the input into
a file. If not, i.e. if you only (can) run the cmdline
version, let me know, then I shall make an extended example-2 version with
a switch to save the input
best
jan
2017-08-21 22:05 GMT+02:00 nottledim <notifications@github.com>:
… I can take recordings, but I don't know how. What should I do?
Dick
On 21 August 2017 19:12:41 JvanKatwijk ***@***.***> wrote:
> Interesting problem. Actually I have no clue.
> Is it possible for you to record a fragment of raw input data that shows
> the problem and send me a link?
> Otherwise, pls add some print statements, there are e.g. two occurrences
of
> showLabel
>
> best
> jan
>
>
> 2017-08-21 15:05 GMT+02:00 jan van katwijk ***@***.***>:
>
>> Forget the previous mail. I have to look into what I have written down
>> there (just cannot follow it anymore)
>> j
>>
>> 2017-08-21 14:04 GMT+02:00 jan van katwijk ***@***.***>:
>>
>>> What might be the case is that the test on the CFlag is ONLY done for
the
>>> first segment, it seems that for successor segments
>>> no C flag is tested. Since I never was confronted with a Cflag 1 that
did
>>> not harm apparently.
>>>
>>> Looking at the code, it seems that whenever the C flag is on, the
>>> behaviour is undefined and depends (a.o) on the value of moreXpad
>>>
>>> To me it seems that an explicit check on the CFlag is needed.
>>> best
>>> jan
>>>
>>>
>>>
>>>
>>> 2017-08-21 11:07 GMT+02:00 nottledim ***@***.***>:
>>>
>>>> Actually, I think I've got it wrong. It's all to do with Cflag. DL+ is
>>>> carried as a DL command so CFlag is 1 whereas your code is for Cflag
=0.
>>>>
>>>> It begs the question why I'm receiving garbage characters.
>>>>
>>>> Thanks
>>>>
>>>> Dick
>>>>
>>>>
>>>>
>>>> On 21 August 2017 08:13:27 JvanKatwijk ***@***.***>
wrote:
>>>>
>>>> > Thanks for the info. I'll have a look this afternoon
>>>> >
>>>> >
>>>> > 2017-08-20 23:54 GMT+02:00 nottledim ***@***.***>:
>>>> >
>>>> >> For some reason I don't receive any DL messages. However the
dataOut
>>>> >> callback does print some garbage characters. So I was looking at
the
>>>> code
>>>> >> and I think there's a misunderstnding. Either mine or yours :-) I
can
>>>> only
>>>> >> find a spec for DL+ so I'm not sure.
>>>> >>
>>>> >> Referring to padHandler::dynamicLabel method in pad-handler.cpp
>>>> >> So far as I can tell the DL command field comprises one byte header
>>>> and
>>>> >> field_1 message bytes. This is why field_1 is specified as one less
>>>> than DL
>>>> >> Command length.
>>>> >>
>>>> >> This makes the header length 3 byes not 2 bytes and affects
dataLength
>>>> >> calculation and the start byte of the message, which should be
>>>> data[3] not
>>>> >> data[2].
>>>> >>
>>>> >> Changing this removes the garbage data problem I was seeing but as
I
>>>> >> receive no real messages I can't test it any further.
>>>> >>
>>>> >> c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/
>>>> >> 01.01.01_60/ts_102980v010101p.pdf
>>>> >>
>>>> >> —
>>>> >> You are receiving this because you are subscribed to this thread.
>>>> >> Reply to this email directly, view it on GitHub
>>>> >> <#14>, or mute
the
>>>> thread
>>>> >> <https://github.com/notifications/unsubscribe-auth/AITzwBoq3
>>>> q5xdJxgAnvrxnQ56AzBWypjks5saKr4gaJpZM4O8vcS>
>>>> >> .
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Jan van Katwijk
>>>> >
>>>> >
>>>> > +31 (0)15 3698980 <+31%2015%20369%208980> <+31%2015%20369%208980>
>>>> > +31 (0) 628260355 <+31%206%2028260355> <+31%206%2028260355>
>>>> >
>>>> >
>>>> > --
>>>> > You are receiving this because you authored the thread.
>>>> > Reply to this email directly or view it on GitHub:
>>>> > #14 (comment)
>>>> mment-323664633
>>>>
>>>> —
>>>> You are receiving this because you commented.
>>>> Reply to this email directly, view it on GitHub
>>>> <#14 (comment)-
323689218>,
>>>> or mute the thread
>>>> <https://github.com/notifications/unsubscribe-auth/AITzwGDc8Zd_
qzxzwhQzENmPO1xKAjW0ks5saUjHgaJpZM4O8vcS>
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> Jan van Katwijk
>>>
>>>
>>> +31 (0)15 3698980 <+31%2015%20369%208980> <+31%2015%20369%208980>
>>> +31 (0) 628260355 <+31%206%2028260355> <+31%206%2028260355>
>>>
>>
>>
>>
>> --
>> Jan van Katwijk
>>
>>
>> +31 (0)15 3698980 <+31%2015%20369%208980> <+31%2015%20369%208980>
>> +31 (0) 628260355 <+31%206%2028260355> <+31%206%2028260355>
>>
>
>
>
> --
> Jan van Katwijk
>
>
> +31 (0)15 3698980 <+31%2015%20369%208980>
> +31 (0) 628260355 <+31%206%2028260355>
>
>
> --
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
> #14 (comment)-
323814422
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwESRRp5SkYaYPDft7ov0JE4MfqQDks5saeMcgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I've shared an item with you:
Shared
https://drive.google.com/drive/folders/0B7sIIKn1Z0BPTjFUNXpLVnNmdFk?usp=sharing&ts=599c8482
It's not an attachment – it's stored online. To open this item, just click
the link above.
This is 1.2G of BBC 6Music transmission on 12B multiplex. I don't know if
this specifically shows the problem but this program is what I mostly use
and they always transmit pad (title artist etc).
https://drive.google.com/drive/folders/0B7sIIKn1Z0BPTjFUNXpLVnNmdFk?usp=sharing
|
|
On 08/22/17 16:54, JvanKatwijk wrote:
If you are able to run Qt-DAB, that has a provision to dump the input into
a file.
There's 1.2G of BBC 6Music here:
https://drive.google.com/open?id=0B7sIIKn1Z0BPcDdkVGp3QXJveUk
I don't know specifically if this shows the problem but I would expect it to
since 6 music transmits program artist title info and I usually what I use
when playing.
Dick
…--
Dick Middleton
dick@lingbrae.com
|
|
Thanks for the link.
Interesting to see that it is all "DAB" rather than DAB+. A quick scan on
my laptop shows that sometimes there is a very brief strange sound (do not
know how to describe it), that suggests that synchronization is lost. I'll
look into it further.
2017-08-22 21:31 GMT+02:00 nottledim <notifications@github.com>:
… On 08/22/17 16:54, JvanKatwijk wrote:
> If you are able to run Qt-DAB, that has a provision to dump the input
into
> a file.
There's 1.2G of BBC 6Music here:
https://drive.google.com/open?id=0B7sIIKn1Z0BPcDdkVGp3QXJveUk
I don't know specifically if this shows the problem but I would expect it
to
since 6 music transmits program artist title info and I usually what I use
when playing.
Dick
--
Dick Middleton
***@***.***
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwD8yq7l68nJcftkVIYa4sZOYnp2Rks5sayyIgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I ran qt-dab both on the laptop and on the rpi2. Result is the same: good
sound, at one point after app minute and a half synchronization
is lost for a very short moment and then a chirp-like sound is heard (which
is caused by the fact that the check on correct MP2 is far
less stringent than the check on correct AAC as is the case with DAB+).
The load on the RPI 2 (controlled headless) is less than 50%. Which brings
me on the following: do you run the RPI with its one
monitor and keyboard and do you have the specrum "on". In that case it
would be good to look at the processor load and the
load on the 4 cores.
best
jan
2017-08-23 15:55 GMT+02:00 jan van katwijk <j.vankatwijk@gmail.com>:
… Thanks for the link.
Interesting to see that it is all "DAB" rather than DAB+. A quick scan on
my laptop shows that sometimes there is a very brief strange sound (do not
know how to describe it), that suggests that synchronization is lost. I'll
look into it further.
2017-08-22 21:31 GMT+02:00 nottledim ***@***.***>:
> On 08/22/17 16:54, JvanKatwijk wrote:
> > If you are able to run Qt-DAB, that has a provision to dump the input
> into
> > a file.
>
> There's 1.2G of BBC 6Music here:
>
> https://drive.google.com/open?id=0B7sIIKn1Z0BPcDdkVGp3QXJveUk
>
> I don't know specifically if this shows the problem but I would expect it
> to
> since 6 music transmits program artist title info and I usually what I use
> when playing.
>
> Dick
>
> --
> Dick Middleton
> ***@***.***
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#14 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AITzwD8yq7l68nJcftkVIYa4sZOYnp2Rks5sayyIgaJpZM4O8vcS>
> .
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/23/17 15:33, JvanKatwijk wrote:
I ran qt-dab both on the laptop and on the rpi2. Result is the same: good
sound, at one point after app minute and a half synchronization
is lost for a very short moment and then a chirp-like sound is heard (which
is caused by the fact that the check on correct MP2 is far
less stringent than the check on correct AAC as is the case with DAB+).
Yes, I heard that too. I don't have a great aerial, or rather it's not in a
good place, so it does lose it sometimes.
The BBC is just DAB. They were an early adopters and are now stuck with it.
The load on the RPI 2 (controlled headless) is less than 50%.
I've got an Orange PI One headless. It's a 4 core H3 processor and it manages
fine.
I've been looking at the PAD messages. It seems that the BBC sends only short
PAD messages with CI flag = 0. However the shortPAD decoder seems to me to
not work and I'm busily trying to write something that does. I have seen
fragments of comprehension in the messages. The short PAD messages should not
be sent to the dynamicLabel routine (if I understand it).
These standards make my head hurt :-)
Dick
…--
Dick Middleton
dick@lingbrae.com
|
|
Jan,
Here's a patch for pad-handler. It receives the BBC PAD data and returns a
string to dataOut. I'm not sure how useful it is.
It's not wonderful - it all seems a strange way to go about life.
You'll have to tweak pad-handler-h because I've changed the prototype to shortPAD.
Each string comprises a number of substrings with a max length of 16 chars.
These substrings have 2 trailing chars - I don't know what they mean but I
think they might be some sort of identifier for the line. They have to be
removed before concatenating the substring into the final string.
Dick
…--
Dick Middleton
dick@lingbrae.com
|
|
Thanks
It seems you forgot the patch itself. Btw yes, the normal way of passing
data is 2 bytes header
and then some characters. The header contains info on whether it is a head,
characterset etc etc
2017-08-23 21:28 GMT+02:00 nottledim <notifications@github.com>:
… Jan,
Here's a patch for pad-handler. It receives the BBC PAD data and returns a
string to dataOut. I'm not sure how useful it is.
It's not wonderful - it all seems a strange way to go about life.
You'll have to tweak pad-handler-h because I've changed the prototype to
shortPAD.
Each string comprises a number of substrings with a max length of 16 chars.
These substrings have 2 trailing chars - I don't know what they mean but I
think they might be some sort of identifier for the line. They have to be
removed before concatenating the substring into the final string.
Dick
--
Dick Middleton
***@***.***
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwMduxYc-lmAUA7MsuOEcVcV-cJesks5sbH1QgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/24/17 10:37, JvanKatwijk wrote:
Thanks
It seems you forgot the patch itself. Btw yes, the normal way of passing
data is 2 bytes header
and then some characters. The header contains info on whether it is a head,
characterset etc etc
I didn't forget. It must have been stripped by github. I've put it on google
drive:
https://drive.google.com/open?id=0B7sIIKn1Z0BPUGExQ1Q4RmhqZDg
It's still not right, I'm missing a trick. Maybe you know what's wrong.
Sometimes messages get concatenated and with ClassicFM the string never gets
sent (so it gets quite big).
There must also be a string identifier of some sort because it keeps repeating
the strings. I read about it somewhere but I can't remember where.
In summary I think the only thing I've achieved is to demonstrate that the BBC
uses shortPAD and the messages can be extracted. It needs to be generalised.
Dick
…--
Dick Middleton
dick@lingbrae.com
|
|
On 08/24/17 10:37, JvanKatwijk wrote:
It seems you forgot the patch itself. Btw yes, the normal way of passing
data is 2 bytes header
and then some characters.
It looks like each segment group has two 7 bit characters appended (trailer).
They're either arbitrary or it's some sort of checksum. I can't see any bit
patterns in it. Do you know anything about that? Quite useful for discarding
repeated messages.
The more I tweak my code the more it looks like your dynamicLabel routine.
Maybe if dynamicLabel could handle the X-PAD subfields (without CI field) it
would save a bit of duplication. Maybe it doesn't matter.
Dick
|
|
I made a new version that displays the shortpad dynlables correctly.
What happens is
the AcTy 2 is the start of a new frame of at most 16 characters, the first
character stored within the pad with ActY 2
then a sequence of No CI's is following each with at most 4 characters. The
amount of characters in the frame is
stored in the AcTy 2 pad.
The full message ends with a AcTy 0 pad
pls give it a try
best
jan
2017-08-24 19:09 GMT+02:00 nottledim <notifications@github.com>:
… On 08/24/17 10:37, JvanKatwijk wrote:
> It seems you forgot the patch itself. Btw yes, the normal way of passing
> data is 2 bytes header
> and then some characters.
It looks like each segment group has two 7 bit characters appended
(trailer).
They're either arbitrary or it's some sort of checksum. I can't see any bit
patterns in it. Do you know anything about that? Quite useful for
discarding
repeated messages.
The more I tweak my code the more it looks like your dynamicLabel routine.
Maybe if dynamicLabel could handle the X-PAD subfields (without CI field)
it
would save a bit of duplication. Maybe it doesn't matter.
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwNo5qli9askc_BKk3xQVkSil8Rhsks5sba5fgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/24/17 18:23, JvanKatwijk wrote:
I made a new version that displays the shortpad dynlables correctly.
The full message ends with a AcTy 0 pad
Yes, that's what I thought. It works for you but not me??? What happened to
those checksums?
pls give it a try
It works (almost) and is neater than my version. Well done.
What doesn't work is ClassicFM. Same problem I found. What you need to do is
detect first (or last) segment and output the buffer. Classic doesn't seem to
send the AcTy == 0. Both BBC and Classic send a number of segments so could
do away with AcTy == 0 case.
Dick
|
|
I'll have a look (and read the DAB standard) tomorrow
best
jan
2017-08-24 21:53 GMT+02:00 nottledim <notifications@github.com>:
… On 08/24/17 18:23, JvanKatwijk wrote:
> I made a new version that displays the shortpad dynlables correctly.
> The full message ends with a AcTy 0 pad
Yes, that's what I thought. It works for you but not me??? What happened to
those checksums?
> pls give it a try
It works (almost) and is neater than my version. Well done.
What doesn't work is ClassicFM. Same problem I found. What you need to do
is
detect first (or last) segment and output the buffer. Classic doesn't seem
to
send the AcTy == 0. Both BBC and Classic send a number of segments so could
do away with AcTy == 0 case.
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwLY60jvW5fR738cNsiJYbSiyOXRwks5sbdTLgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Closer look at the data reveals that the AcTy 2 segment contains - next to
the databyte - 3 relevant values,
the length of the text to follow, the segment number and the indication
first/last/intermediate segment
Using the latter now for recognizing the first and last segment of the
messag.
So, no more dependency on AcTy 0
best
jan
2017-08-24 21:53 GMT+02:00 nottledim <notifications@github.com>:
… On 08/24/17 18:23, JvanKatwijk wrote:
> I made a new version that displays the shortpad dynlables correctly.
> The full message ends with a AcTy 0 pad
Yes, that's what I thought. It works for you but not me??? What happened to
those checksums?
> pls give it a try
It works (almost) and is neater than my version. Well done.
What doesn't work is ClassicFM. Same problem I found. What you need to do
is
detect first (or last) segment and output the buffer. Classic doesn't seem
to
send the AcTy == 0. Both BBC and Classic send a number of segments so could
do away with AcTy == 0 case.
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwLY60jvW5fR738cNsiJYbSiyOXRwks5sbdTLgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/25/17 11:05, JvanKatwijk wrote:
Using the latter now for recognizing the first and last segment of the
messag.
So, no more dependency on AcTy 0
Good, except one thing: you need to call dataOut - oops :-)
Dick
|
|
Jan,
No, sorry, I see what you've done. The problem was:
if ((b [last - 1] & 0xF0) == 0x40) {
should be if ((b [last - 1] & 0x40) == 0x40) {
Dick
|
|
You are right!!! stupid of me. I'll correct it for both the first and last
segment (all those details ... )
2017-08-25 15:31 GMT+02:00 nottledim <notifications@github.com>:
… Jan,
No, sorry, I see what you've done. The problem was:
if ((b [last - 1] & 0xF0) == 0x40) {
should be if ((b [last - 1] & 0x40) == 0x40) {
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwP03a77w-gNlG0YtkMC0rOUKK3pMks5sbszEgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/25/17 15:22, JvanKatwijk wrote:
You are right!!! stupid of me. I'll correct it for both the first and last
segment (all those details ... )
I've cleaned out the cruft and simplified it slightly. It works just fine on
BBC and ClassicFM.
https://drive.google.com/open?id=0B7sIIKn1Z0BPWkNmN29wQkk1ZmM
Dick
|
|
Thanks
firstSegment, lastSegment and still_to_go are now class variables rather
than statics, and there is no need for the data array anymore.
best
jan
2017-08-25 16:25 GMT+02:00 nottledim <notifications@github.com>:
… On 08/25/17 15:22, JvanKatwijk wrote:
> You are right!!! stupid of me. I'll correct it for both the first and
last
> segment (all those details ... )
I've cleaned out the cruft and simplified it slightly. It works just fine
on
BBC and ClassicFM.
https://drive.google.com/open?id=0B7sIIKn1Z0BPWkNmN29wQkk1ZmM
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwLDAeL7nL-2lh5e520Xv5f_ep_bWks5sbtlRgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
On 08/25/17 15:47, JvanKatwijk wrote:
firstSegment, lastSegment and still_to_go are now class variables rather
than statics, and there is no need for the data array anymore.
best
Should toStringUsingCharset be applied to the message? I assume the CharSet
is in the prefix as in dynamicLabel.
Also I've noticed incomplete message when changing channels. Probably because
the first segment received isn't the first segment (if you follow). Should
there be a defense against that? Such as a segment counter compared to
segment number.
Dick
|
|
Yes
to do it really good we should take charsets and broken messages into
account. The latter is easy in the dab-cmdline verion,
just check that the ecoming segment follows the last segment and ignores is
we are out of sync
But, while technically fairly easy to address, it shows the more - almost -
philosophical - issue of whether you want only
complete messages or all messages
The Charset and C++ are not easy to handle since there is no real support
for charsets in C++11. In the Qt-DAB version that is easy to handle.
jan
2017-08-25 17:16 GMT+02:00 nottledim <notifications@github.com>:
… On 08/25/17 15:47, JvanKatwijk wrote:
> firstSegment, lastSegment and still_to_go are now class variables rather
> than statics, and there is no need for the data array anymore.
> best
Should toStringUsingCharset be applied to the message? I assume the CharSet
is in the prefix as in dynamicLabel.
Also I've noticed incomplete message when changing channels. Probably
because
the first segment received isn't the first segment (if you follow). Should
there be a defense against that? Such as a segment counter compared to
segment number.
Dick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwIhGpJjEeTnOnL3Nt6VjucCzZrSsks5sbuUwgaJpZM4O8vcS>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For some reason I don't receive any DL messages. However the dataOut callback does print some garbage characters. So I was looking at the code and I think there's a misunderstnding. Either mine or yours :-) I can only find a spec for DL+ so I'm not sure.
Referring to padHandler::dynamicLabel method in pad-handler.cpp
So far as I can tell the DL command field comprises one byte header and field_1 message bytes. This is why field_1 is specified as one less than DL Command length.
This makes the header length 3 byes not 2 bytes and affects dataLength calculation and the start byte of the message, which should be data[3] not data[2].
Changing this removes the garbage data problem I was seeing but as I receive no real messages I can't test it any further.
c.f. http://www.etsi.org/deliver/etsi_ts/102900_102999/102980/01.01.01_60/ts_102980v010101p.pdf
The text was updated successfully, but these errors were encountered: