So I purchased this device from a company in china thinking, I'm savvy, I'll be able to figure it out.
http://www.ebay.com/itm/RS232-DC-12V-8Ch-Serial-control-computer-control-switch-Relay-Board-Module-/261695306230?hash=item3cee4179f6:g:UVwAAOSwWnFWBPYq
Well now that I have it, I can not figure out RS232 commands to issue and I can not find a manual anywhere. I've tried looking at similar devices and issuing commands like "FF 01 01" which equates to "addressofboard, relay, state" in other similar devices. Can anyone help me find a manual or has anyone ever used this thing?
I finally got a reply from the manufacturer. It's so complicated that I would have never guess the correct order. Here are the commands:
Close 1 channel：56 01 13 00 00 01 01 6C
Open 1 channel ：56 01 13 00 00 01 00 6B
Close 2 channel：56 01 13 00 00 02 02 6E
Open 2 channel：56 01 13 00 00 02 00 6C
Close 3 channel：56 01 13 00 00 04 04 72
Open 3 channel：56 01 13 00 00 04 00 6E
Close 4 channel：56 01 13 00 00 08 08 7A
Open 4 channel：56 01 13 00 00 08 00 72
Close 5 channel：56 01 13 00 00 10 10 8A
Open 5 channel：56 01 13 00 00 10 00 7A
Close 6 channel：56 01 13 00 00 20 20 AA
Open 6 channel：56 01 13 00 00 20 00 8A
Close 7 channel：56 01 13 00 00 40 40 EA
Open 7 channel：56 01 13 00 00 40 00 AA
Close 7 channel：56 01 13 00 00 80 80 6A
Open 7 channel：56 01 13 00 00 80 00 EA
The structure is weird to me but I'm sure it makes sense somewhere:
(data, device address, function, empty, empty, relay, state, checksum)
The checksum is an addition of all the values and taking the 8th value of that addition.
Related
I'm working on understanding a mystery protocol in a DLP 3d printer. A raspberry pi is talking to a motor/led controller via a serial bus. The device seems to be proprietary but I'm guessing it uses some kind of open standard (like GCode). It may help to know the device was probably made and programmed in china. No idea if this factors but there may be some programming cultural thing I'm missing. I'm trying to figure out how to control this motor/led control board via the serial port so I captured data using interceptty.
This seems to be an idle state sent to the mystery device from the pi.
55 55 55 55 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 08 aa aa aa aa
This tends to be how the mystery device acknowledges
55 55 55 55 00 03 00 00 00 00 00 00 00 00 00 00 00 00 01 04 aa aa aa aa
55 55 55 55 00 03 00 00 00 00 00 00 00 00 00 00 00 00 01 04 aa aa aa aa
This seems to be noting an idle state always after acknowledgement from the mystery device.
55 55 55 55 00 03 00 00 00 00 00 00 00 00 00 00 00 00 55 58 aa aa aa aa
This is a command that started the print off. So this begins moving a motor.
55 55 55 55 00 03 e8 03 00 00 40 0d 03 00 01 00 00 00 00 3f aa aa aa aa
For reference 55555555 and aaaaaaaa are 01010101 etc in binary. They seem to be a way to clear coms for async serial transmission. It certainly LOOKS like I'm seeing extremely low level communication. As if I hooked a logic analyzer up to the circuit.
There are 16 hex bytes in between each of these clearing/syncing steps. I'm not sure if I'm just seeing VERY low level communication or if these 16 bytes contain all of the data in any given command or the data plus check bytes or something.
Finally, I'm seeing LOTS of repetition. This leads me to think that this isn't Gcode but that the pi is sending a command every cycle and the slave/mystery device is updating as quickly as possible.
For example the output below repeats over and over 1145 times after starting a print. This would be when the motor has descended fully into a vat and an LED is held on for an extended period of time. > denotes received transmissions < denotes outgoing transmissions from the pi.
> 55 55 55 55 00 03 00 00 00 00 | UUUU
> 00 00 00 00 00 00 00 00 01 04 |
> aa aa aa aa 55 55 55 55 00 03 | UUUU
> 00 00 00 00 00 00 00 00 00 00 |
> 00 00 01 04 aa aa aa aa |
< 55 55 55 55 00 03 20 03 00 00 | UUUU
< 78 5d 02 00 00 00 00 00 00 fd | x]
< aa aa aa aa |
I'm hoping to get some direction. None of this hex seems to translate well into ascii or utf. I don't think it's passing ints or chars. Maybe it's backwards bitwise? I'm not sure. I'm having lots of trouble making heads or tails of it.
What level is UUUU and aaaa at? It seems like something you'd see on a logic analyzer not from through a driver.
Anyway, any direction would be much appreciated.
Here follows the hex dump of the MPEG2VideoDescriptor:
06 0e 2b 34 02 53 01 01 0d 01 01 01 01 01 51 00
83 00 00 f3 3c 0a 00 10 a3 be 51 b2 00 05 e7 11
bf 82 21 97 f7 a0 14 ed 30 06 00 04 00 00 00 02
30 01 00 08 00 00 ea 60 00 00 03 e9 80 00 00 04
01 c9 c3 80 30 04 00 10 06 0e 2b 34 04 01 01 02
0d 01 03 01 02 04 61 01 32 15 00 01 05 32 0e 00
08 00 00 00 10 00 00 00 09 32 0d 00 10 00 00 00
02 00 00 00 04 00 00 00 1a 00 00 00 00 32 0c 00
01 00 32 08 00 04 00 00 02 d0 32 09 00 04 00 00
05 00 32 02 00 04 00 00 02 d0 32 03 00 04 00 00
05 00 32 01 00 10 06 0e 2b 34 04 01 01 03 04 01
02 02 01 04 03 00 33 02 00 04 00 00 00 02 33 08
00 04 00 00 00 01 33 03 00 01 04 33 01 00 04 00
00 00 08 33 0b 00 01 00 33 07 00 02 00 00 33 04
The first 16 bytes:
06 0e 2b 34 02 53 01 01 0d 01 01 01 01 01 51 00 (UID)
Next 4 bytes is the BER size:
83 00 00 f3 (0xf3 bytes long)
Next 4 bytes:
3c 0a 00 10 (0x3c0a means Instance UUID and 0x0010 is the size)
Then follows the UUID:
a3 be 51 b2 00 05 e7 11 bf 82 21 97 f7 a0 14 ed
Next 4 bytes:
30 06 00 04 (0x3006 means Linked Track ID and 0x0004 is the size)
Next 4 bytes is the Linked Track ID: 00 00 00 02
Next 4 bytes: 30 01 00 08 (0x3001 means Sample Rate and 0x0008 is the size)
The following 8 bytes are actually frame rate numerator and denominator:
0000ea60 == 60000 and 000003e9 == 1001.
Now we have the bold part: 80 00 00 04
.
Can somebody please explain what does it mean?
The next four bytes are 01 c9 c3 80 and it is definitely the bitrate (30000000), but how can I know that for sure?
Edit:
Does 80 00 00 04 mean the following:
0x8000 is a dynamic tag. According to SMPTE 337, tags 0x8000-0xFFFF are dynamically allocated. The 0x0004 is the size (4 bytes). If that's true, how can I tell that the following 4 bytes 01 c9 c3 80 are actually the bitrate? It could be anything, or?
First you have to understand how local tags work.
Local tags 0x8000 and above are user defined.
You have to look at the primer pack of the header partition.
The primer pack translates the local tag to a global UL which may or may not be vendor specific.
Consider the primer pack being a translation table between the 2 byte local tag and the 16 byte UL.
I am trying to return hexadecimal string as response from my AWS Lambda function. When it reaches to the client the data seems to be modified.
Data :
47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00
ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00
01 00 01 00 00 08 04 00 03 04 04 00 3b
Hexadecimal Excaped Data ( Sent Data ):
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00\x00"
"\xff\xff\xff\x21\xf9\x04\x01\x00\x00\x01\x00\x2c\x00\x00\x00\x00"
"\x01\x00\x01\x00\x00\x08\x04\x00\x03\x04\x04\x00\x3b
Received Data
47 49 46 38 39 61 01 00 01 00 c2 80 00 00 00 00
00 c3 bf c3 bf c3 bf 21 c3 b9 04 01 00 00 01 00
2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04
00 3b
How to fix this?
Last time I checked it was not very explicit in the doc, but API Gateway is really made for json (or similar) and support for binary is 'on the roadmap' but clearly doesn't seem to be a priority. It converts everything it sends to utf-8.
Comparing precisely your original data with the received one you can see it :
47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00 ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b
47 49 46 38 39 61 01 00 01 00 c2 80 00 00 00 00 00 c3 bf c3 bf c3 bf 21 c3 b9 04 01 00 00 01 00 2c 00 00 00 00 01 00 01 00 00 08 04 00 03 04 04 00 3b
Everything under 0x7f is OK because the unicode code point is the same as the encoded byte (U+0047 -> 47), but for 0x80 or more the problem arises : U+0080 -> c2 80, U+00FF -> c3 bf and so on.
We had a similar problem recently : binary data was corrupted and bigger when sent through Gateway than with direct access to our backend. It was because a lot of bytes get replaced by Unicode special 'replacement character' aka 'U+FFFD' aka '0xEF 0xBF 0xBD'.
How to fix ? We just stopped using Gateway but if you can afford your data to be bigger, you can base64 encode it.
I'm trying to do some reverse engineering on my heating system. Monitoring the CAN BUS results in receiving hexademical strings, for example:
00 D0 68 D6 86 83 61 8F
61 C0 02 5C 12 B5 02 5C
12 78 04 39 04 03 05 02
05 C4 04 5C 12 5C 12 5C
12 5C 12 D0 68 00 00 00
00 18 08 37 D2 00 00 00
00 00 00 00 00 15 75 F2
F0 01 00 01 00 00 00 1F
I know that for example the temperature value of 22.5°C should be somewhere in there.
So far I have tried to look for the following conversions:
Possibility 1: ascii to hex
22.5 = 32 32 2E 35
Possibility 2: float to hex conversion
22.5 = 0x 41 b4 00 00
However none of these resulted in a match.
What would be other possibilities to converted a float to a hex string?
Thx
note: the given string is just a small part of my can sniffer so don't look for 22.5 in my given string here. I'm just looking for other possible conversions.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I've recorded some network traffic in my home that only appear up while running BitTorrent or uTorrent.
I've been reading the bittorrent protocol descriptions, but I am stuck trying to figure out a particular network flow.
Can someone help me identify what the following bittorrent network traffic is exactly?
It lasts quite a long time, even after stopping downloads.
All packets are in one direction - from my local machine running Bittorrent to a remote machine.
Here is data payload of one packet (copied from Wireshark):
00000000 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000010 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000020 20 5a 01 45 bd 13 b1 65 01 04 44 4a e7 d5 04 04 Z.E...e ..DJ....
00000030 01 00 00 00 05 02 ea cf ........
All the packets in the network flow are similar, here are two more:
00000038 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000048 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000058 20 5a 01 45 bd 13 b1 65 01 04 08 8e 35 9f 04 04 Z.E...e ....5...
00000068 01 00 00 00 05 02 ea cf ........
00000070 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000080 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000090 20 5a 01 45 bd 13 b1 65 01 04 12 3e ba 6c 04 04 Z.E...e ...>.l..
000000A0 01 00 00 00 05 02 ea cf ........
These bittorrent packets are typically several seconds apart, and this flow seems to go on indefinitely. Which one of the bittorrent protocols describes this network flow?
I just sent a response to you on our mailing list, but I'm gonna post here too in case anyone else stumbles across it and finds it useful.
They're Teredo packets (with no payload). Wireshark can decode these
but it doesn't do so without coercion.
http://en.wikipedia.org/wiki/IPv6_packet
http://en.wikipedia.org/wiki/Teredo_tunneling
One of your packets dissected:
IP Version: 6
Traffic Class: 0 0
Flow Label: 0 00 00
Payload Length: 00 00
Next Header: 3b (indicates that there is no payload present)
Hop Limit: 15
Source: 20 01 00 00 9d 38 6a b8 04 b9 18 bf 9c 90 d8 81
Destination: 20 01 00 00 9d 38 6a b8 20 5a 01 45 bd 13 b1 65
The source and destination also encode the source and destination
public ipv4 addresses and ports.
The hop-by-hop options header (in type-length-value format) follows in
this case. The possible types can be found here:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
So we have this:
01 04: c3 ae 60 38 ("PadN", random bytes)
04 04: 01 00 00 00 ("Tunnel Encapsulation Limit")
05 02: ea cf ("Router Alert")
No clue what the value of the router alert field is here. I would
expect it to be listed here:
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xml
But it looks like either that's out of date or the Teredo
implementation you're using is doing something non-standard (or
there's something I've missed).
Anyways, these are clearly keep-alive packets. We're not directly
triggering them in the client as far as I know. I believe they're sent
by your Teredo driver to keep your tunnels open.