Revert "library/PCUIF_Types.ttcn: inform RAW codec about PADDING in PCUIF_data"
This reverts commit dd6d5d1baa62dc9d50fa90ef01fccb8a10284d53.
The PADDING seems to be a very experimental feature of TITAN. It works
very well for decoding of messages, so the padding bytes are getting
recognized as expected, but encoding is broken. Not only the data
buffer and its length are encoded in a wrong way, but other fields too.
Change-Id: Ieefa61232eb215a19a02e490255332e28e23b8f8
diff --git a/library/PCUIF_Types.ttcn b/library/PCUIF_Types.ttcn
index 721eb64..27d9b92 100644
--- a/library/PCUIF_Types.ttcn
+++ b/library/PCUIF_Types.ttcn
@@ -77,15 +77,10 @@
PCUIF_Text text
} with { variant "" };
-/* This is a bad side of the current protocol design: fixed-size buffer is located
- * in between the other fields of the message, so if the payload is smaller than
- * 162 octets (1296 bits), we need to fill the remaining space with padding. */
-type octetstring PCUIF_DataPad with { variant "ALIGN(left), PADDING(1296)" };
-
type record PCUIF_data {
PCUIF_Sapi sapi,
uint8_t len,
- PCUIF_DataPad data,
+ octetstring data length(162),
uint32_t fn,
uint16_t arfcn,
uint8_t trx_nr,
@@ -95,7 +90,7 @@
uint16_t ber10k,
int16_t ta_offs_qbits,
int16_t lqual_cb
-} with { variant (len) "LENGTHTO(data)" };
+} with { variant (data) "FIELDLENGTH(162), ALIGN(left)" };
type record PCUIF_data_cnf_dt {
PCUIF_Sapi sapi,