Any chance the device is faulty?
Maren Purves East Asian Observatory / JCMT
Dear Dirk,
I didn't expect that the device itself would randomly send a value
of \x00 along with the expected data.
I checked it using a simple Python code, and it seems to be a signal
sent from the device.
Thus this issue seems to have nothing to do with Streamdevice.
I think I need to take a look at my device.
Thank you for the comment.
Best regards,
Hyung Jin Kim
On 9/18/23 18:44, Zimoch Dirk wrote:
Hello Hyung Jin Kim,
Unfortunately, I cannot reproduce your problem.
I have set up a simulation server that always sends the sequence
"\x16\x16\x80\x00\x08\x00\x80\x22\x43\x00\x00\xc0\x40\x6d\x1a"
I have no problem at all to read this. It always shows as expected:
2023/09/18 11:18:38.028 localhost:40000 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
This is read as the value 162.5.
I never got unexpected 00 bytes. The only way to get it is to modify the server
to actually send "\x00" in between the expected data.
Thus I guess, your devices actually does this.
However, the protocol fails when 0x1a is part of value or checksum. Therefore, I
changed the protocol to:
MaxInput=16;
query_head = "\x16\x16\x80";
query_tail = "\x00%2<sum8>";
get_dev_info
{
out $query_head "\x00" $query_tail;
in $query_head "\x00\x08"
"%#4R"
"%2<sum8>\x1a";
}
Note that now "\x1a" at the end needs to be read explicitly.
Of course, this does not solve the problem with the unexpected 00 bytes.
We need to find out what is happening on your network.
Can you capture the network traffic between your device and your IOC with
wireshark (or tcpdump or similar)?
What happens if you set SCAN=Passive? Does the device still send 00?
Are there any other records in your IOC that may make your device sending 00?
BTW: I strongly recommend to never use 'ExtraInput = Ignore;' except you really,
really know you really, really, really need it.
Dirk
On Fri, 2023-09-15 at 15:27 +0900, Hyung Jin Kim via Tech-talk wrote:
Dear All,
We have some device controlled via raw serial communication. Streamdevice reads a weird 1 byte null data (as far as we are understanding).
We expect that 15 byte data are read back normally when 7 byte command is sent.
send cmd: 0x16 0x16 0x80 0x00 0x00 0x80 0x1A
read-back: 0x16 0x16 0x80 0x00 0x08 (two 4 byte float) checksum 0x1A
However, unexpected 1 byte null(\x00) character is read. Sometimes, this null character is read together with our read-back data, which causes an input error as shown in iocshell console message.
Do you have any idea about this?
Thanks,
Hyung JIn Kim
=================================================================
iocshell console message:
2023/09/15 10:57:29.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:29.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:29.912 192.168.85.191:4001 read 1
00
2023/09/15 10:57:31.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:31.895 192.168.85.191:4001 read 1
00
2023/09/15 10:57:31.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:31.912 192.168.85.191:4001 read 1
00
2023/09/15 10:57:32.913154 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: Input "<00><16><16><80><00><08><00><80>"C<00><00><c0>@m<1a><00>"
2023/09/15 10:57:32.913470 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: mismatch after 0 bytes ""
2023/09/15 10:57:32.913730 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: got "<00><16><16><80><00><08><00><80>"C..." where "<16>" was expected
2023/09/15 10:57:33.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:33.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:33.912 192.168.85.191:4001 read 1
00
2023/09/15 10:57:35.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:35.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:35.912 192.168.85.191:4001 read 1
00
2023/09/15 10:57:37.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:37.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:37.911 192.168.85.191:4001 read 1
00
2023/09/15 10:57:39.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:39.895 192.168.85.191:4001 read 1
00
2023/09/15 10:57:39.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:40.904437 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: Input "<00><16><16><80><00><08><00><80>"C<00><00><c0>@m<1a>"
2023/09/15 10:57:40.904748 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: mismatch after 0 bytes ""
2023/09/15 10:57:40.905012 PHWRB41 SCL32-RF03:SSPA-B41:#getInfo: got "<00><16><16><80><00><08><00><80>"C..." where "<16>" was expected
2023/09/15 10:57:41.891 192.168.85.191:4001 write 7
16 16 80 00 00 80 1a
2023/09/15 10:57:41.903 192.168.85.191:4001 read 15
16 16 80 00 08 00 80 22 43 00 00 c0 40 6d 1a
2023/09/15 10:57:41.911 192.168.85.191:4001 read 1
00
...
===========================================================================
For reference, here is a part of our protocol:
Terminator = "\x1A";
ExtraInput = Ignore;
query_head = "\x16\x16\x80";
query_tail = "\x00%2<sum8>";
get_dev_info
{
Separator = "";
out $query_head "\x00" $query_tail;
in $query_head "\x00\x08"
"%#4R"
"%2<sum8>";
}
Our database is as follows:
record(aai, "${SYS}${SUBSYS}${DEV}${SUBDEV}#getInfo") {
field (DESC, "Get Freq and Firmware")
field (SCAN, "2 second")
field (DTYP, "stream")
field (INP, "@sspaRFPT.proto get_dev_info(${SYS}${SUBSYS}${DEV}${SUBDEV}) $(PORT)")
field (NELM, "2")
field (FTVL, "FLOAT")
}
===========================================================================
Our st.cmd looks like :
...
drvAsynIPPortConfigure("PHWRB41", "192.168.85.191:4001", 0,0,0)
asynSetOption("PQWR001", 0, "baud", "115200")
#asynSetOption("PQWR001", 0, "bits", "8")
#asynSetOption("PQWR001", 0, "stop", "1")
#asynSetOption("PQWR001", 0, "parity", "none")
...
asynSetTraceMask ("PHWRB41", 0, 9)
asynSetTraceIOMask("PHWRB41", 0, 4)
dbLoadTemplate("${TOP}/db/sspaRFPT.substitutions", "")
...
- References:
- Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
- Re: Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Navigate by Date:
- Prev:
Re: Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Next:
Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
- Navigate by Thread:
- Prev:
Re: Streamdevice reads weird 1 byte null data Hyung Jin Kim via Tech-talk
- Next:
Re: Streamdevice reads weird 1 byte null data Zimoch Dirk via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
|