Open steven-efsi opened 1 year ago
When using a COMMAND packet with a BLOCK type, on cosmos 4 one could input raw hex string for the BLOCK data.
cmd("TARGET COMMAND with DATA 0xdeadbeef")
On cosmos5, this works only if all characters are ascii data.
For example, with 0x304030, and a simple protocol in write_packet:
blah = packet.read('DATA') Logger.info "blah is #{blah}" Logger.info "blah bytes is #{blah.bytes}"
Yields:
blah is 0@0 blah bytes is [48, 64, 48]
If I send 0xdeadbeef:
blah is {"json_class"=>"String", "raw"=>[222, 173, 190, 239]} blah bytes is [123, 34, 106, 115, 111, 110, 95, 99, 108, 97, 115, 115, 34, 61, 62, 34, 83, 116, 114, 105, 110, 103, 34, 44, 32, 34, 114, 97, 119, 34, 61, 62, 91, 50, 50, 50, 44, 32, 49, 55, 51, 44, 32, 49, 57, 48, 44, 32, 50, 51, 57, 93, 125]
The data sent out the interface reflects this, and it's wrong.
For reference, the byte code starting at byte 2 spells out "json_class"
Thanks!
This bug does not exist in openc3, so we had to move to it.
When using a COMMAND packet with a BLOCK type, on cosmos 4 one could input raw hex string for the BLOCK data.
cmd("TARGET COMMAND with DATA 0xdeadbeef")
On cosmos5, this works only if all characters are ascii data.
For example, with 0x304030, and a simple protocol in write_packet:
blah = packet.read('DATA') Logger.info "blah is #{blah}" Logger.info "blah bytes is #{blah.bytes}"
Yields:
blah is 0@0 blah bytes is [48, 64, 48]
If I send 0xdeadbeef:
blah is {"json_class"=>"String", "raw"=>[222, 173, 190, 239]} blah bytes is [123, 34, 106, 115, 111, 110, 95, 99, 108, 97, 115, 115, 34, 61, 62, 34, 83, 116, 114, 105, 110, 103, 34, 44, 32, 34, 114, 97, 119, 34, 61, 62, 91, 50, 50, 50, 44, 32, 49, 55, 51, 44, 32, 49, 57, 48, 44, 32, 50, 51, 57, 93, 125]
The data sent out the interface reflects this, and it's wrong.
For reference, the byte code starting at byte 2 spells out "json_class"
Thanks!