Hi fellow DataMiner's,
I am having some issues when receiving UDP data of variable length via smart-serial.
I have a protocol with two connections, one serial, and another a smart-serial which is configured to listen to "any" traffic on a specific port.
In the protocol I have the following response configured, targeting the smart-serial connection.
<Response id="1" options="Connection:1">
<Name>BroadcastMessage</Name>
<Description>Broadcast Message</Description>
<Content>
<Param>68</Param>
</Content>
</Response>
Following the guidance written in the docs here in the notice section it mentions the following.
In some cases, data received via a smart-serial connection is not delimited by a specific header and trailer. The data source can send all data as one package, without specific delimiters. In that case, we must define a response with a parameter of type "next param" to capture all data (and process it later on in e.g. a QAction).
So for the above content param, I did the following.
<Param id="68">
<Name>Message</Name>
<Description>Message</Description>
<Type>read</Type>
<Interprete>
<RawType>other</RawType>
<LengthType>next param</LengthType>
<Type>string</Type>
</Interprete>
</Param>
When a message is received on the smart-serial, it will correctly trigger the QAction to process the message, but unfortunately, the contents of the parameter are empty.
If I change the parameter to be of a fixed length like below.
<Param id="68">
<Name>Message</Name>
<Description>Message</Description>
<Type>read</Type>
<Interprete>
<RawType>other</RawType>
<LengthType>fixed</LengthType>
<Length>29</Length>
<Type>string</Type>
</Interprete>
</Param>
I am now able to see the full payload.
C0-A8-C0-8B-08-17-00-00-00-00-01-02-00-01-01-01-48-65-6C-6C-6F-20-57-6F-72-6C-64-21-00
Sadly this is not practical, and although the first 16 bytes can be accounted for the rest varies in length. I am also unable to utilise the header-tailer option as the payload does not contain a trailer.
Any help would be greatly appreciated.
Thanks
Hi Aston,
As soon as a response contains some 'next param' parameters, a read response action should be used in order to properly fill in those parameters.
Such action should be called by a before response trigger.
More info here: Creating commands and responses | DataMiner Docs
Are you using that?
Side question, quite typically, when receiving messages of variable length, the message itself indicates the length at a fix location. If this is the case, you can smooth the process by defining that in the protocol. More info on that can be found here: Creating commands and responses | DataMiner Docs
regards,
Hi Aston, given that each UDP packet already contains all the required data, it’s advisable to also enable the ‘FlushPerDatagram’ option in the port settings. This setting ensures that DataMiner doesn’t buffer and aggregate multiple packets before transmitting them to the element.
See https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.PortSettings.FlushPerDatagram.html.
Hi Simon,
Thank you very much for your reply.
I was indeed missing the Read Response Action and is now working with this in place. Sadly the data being received doesn’t contain the payload length. The vendor does have this in place for TCP traffic, but these broadcast messages are only sent via UDP. Once again thanks for your help, I like easy fixes 🙂