Learned more about the response. It's like "0DH [X1] [X2] xxxxxxx 20H 20H 0DH 4CH 32H xxxxxxx 20H 20H 0DH 4CH 33H xxxxxxx 20H 20H 0DH", in which [X1] may be letter 'A','B' or 'C', and [X2] is a single digit.
Tryed to split it into 3 parts using 3 data points, each of which ended with "20H 20H 0DH". A sample of the first part is in the screenshot attached.
But "patternMismatch" alarms showed up.
Screenshots of Serial Data Source Configuration, alarm, and event in Mango database are attached.
As may not be seen directly in the screeshot, there are two spaces in both message terminator and message regex. Whole strings are written below:
Message Terminator: [space][space]\r
Message Regex: (?s)([A-CL][0-9].*)[space][space]\r
Embbeded flag expression (?s) is used because there are several single '0DH' in the "xxxxxxxx" part of the response. So the ".*" can match them.
I took out the piece of "messageMatcher" java code from SerialDataSourceRT.java, and tested it with sample message and regex above. It was a match. And I got to find the problem elsewhere.
Now it seems to me there is only one space left in the message and the regex, seen from the highlighted parts of the screenshots. Not sure that is a display issue or really a clue.
What do you see, Philips?
The difference from what you'd expect in the resulting terminator using the \s is because Java escape characters are different than regular expression escape characters (spaces are okay with Java). This is unclear, I should probably add that to the documentation.
Unfortunately no, the serial data source wasn't written for protocols that are length dependent or have ambiguous terminators. I think the existing solution is to use the same trick and buffer the serial data into a meta point, then shuffle it to the right point from a script.
Attachment: download link