Dear Juan,many thanks for this hints. You are perfectly right, some wrong numbers have made it into the document, which need to be corrected before publication.
For curiosity I checked the earlier versions of the drafts and it looks as if the first problem of this kind (calculating the Length field as being length of SNDU including header, so 4 bytes too much) first occurred in the Feb 2004 -02 version, (was actually meant as an improvement for reading: instead of showing the SNDU bytes from 0 to length-1 to also provide the Length field values). In the Oct 2004 -02 version this first calculation error was corrected for the first example, but at the same time the second example was "improved" with completely obscure numbers (6x instead of Bx). Funny enough, in the same -02 version another two examples were correctly improved, yet another one with same kind of +4 calculation.
Apart from Yuan, again many thanks for this detailed reading, no one seems to have recalculated or cross checked the numbers again since then.
Rethinking this style of reading improvement it does not seem to be such that the examples are easier to understand at all. If one takes for example the first part of Example A.5 (is just the shortest one) I find it not that clear any more that SNDU A having length 52 (4B hdr plus 48B payload) is to be counted from A000 to A051 on one side, but since the SNDU Length field is shown the counting actually has to start with A002 o nthe other side.
Any hints for improvement?
Example A.5: Three 44B PDUs.
SNDU A is 52 bytes (no ULE destination NPA address)
SNDU B is 52 bytes (no ULE destination NPA address)
SNDU C is 52 bytes (no ULE destination NPA address)
The sequence comprises 1 TS Packet:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+-----+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * *
*****
The sequence comprises 1 TS Packet:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+-----+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 |0x80 | 0x34 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+-*----+-----+- -+-----+-
PUSI=1 * *
*****
Regards,
Bernhard
Gorry Fairhurst wrote:
Juan, thanks for the query it's easy to miss mistakes in the informative annexes, and we'd certainly like to get the text correct before this is published as a RFC.Can someone please check this out (I can't at the momment) Gorry Juan Cantillo wrote:Dear Gorry,I am currently working on the "01 version" of our DVB-S2 draft and while re-reading the ULE-06 draft I came across what might be some typographic errors in ANNEX A: ********************* Page 38, example A2 "Usage of last byte in a TS packet":*************** The 4 shown SNDU sizes are 183, 182, 181 and 185 Bytes long, which would lead to "SNDU Length" fields of 0xB3, 0xB2, 0xB1and 0xB5, resp, since:0xB3 = 183 - 4 (in decimal) 0xB2 = 182 - 4 0xB1 = 181 - 4 0xB5 = 185 - 4(4 bytes are to be substracted to the length of the SNDU since the "SNDU Length" field DOES NOT count the 4-byte mandatory header of ULE) Instead, in the diagram we have 0x63, 0x62, 0x61and 0x65... it seems that the "B" was confused with "6" ?! ********************* Page 41, example A5 "three 44B PDUs":******************************** The three SNDUS are 52 bytes long, which would lead to "SNDU Length" of 48 bytes, coded in hexadecimal as 0x30 and NOT as 0x34. Please let me know whether those are typographic mistakes, or if it is me who is wrong... This last hypothesis is highly probable since "the errors" are similar, so I might be missing something! Looking forward to hearing from you soon, Juan =========================Juan CANTILLO SatComs PhD. Researcher ENST/TeSA/ENSICA/ASP +33 6 23 54 59 65 Toulouse, FR