0
\$\begingroup\$

I am trying to rewrite a small utility tool for my bike computer Mio 105. Unfortunately there is not any API to do that, so the only thing left is reverse engeneering. So I have set up a USB sniffer and used orginal software to communicate with the device. I managed then to write a piece of code which was able to communicate too, the port was set up correctly, but there is a problem how it works. In original soft data is being transfered in bigger packages (up to 4kB) but in my code I had to read one byte by one. So here is the question: how to achieve something like this packages automatically?

I used Serial Port Monitor to watch a USB port. Here's an example of data being sent: https://pastebin.com/SdePj58x When I manually open the port using this program I can see that RTS and DTR are turned on. Sending one particular hex code results in the same answer from device like given before. Is this communication somehow standarized or these hex-code commands are specific for this device and I need then to hardcode them inside my program?

\$\endgroup\$
  • 1
    \$\begingroup\$ You should post a sample of the comms capture into your question using the {code} button to format it correctly. You'd probably need to add some comments. Other than that I'm afraid I can't help. Welcome to EE.SE. \$\endgroup\$ – Transistor May 17 '18 at 7:32
2
\$\begingroup\$

The low-level protocol seems to be fairly straightforward.

The host messages always start with 0x02, followed by two bytes of length (big-endian, most often 0x00 0x01 = 1). This is followed by length bytes of data (some sort of command byte or register address, sometimes with additional data) and a one-byte checksum of some sort.

The replies from the device have a similar structure. The first byte is a repeat of the command/address byte that the host sent, followed by two bytes of length, length bytes of data, and the checksum.

Beyond that, the meaning of the data fields is probably completely proprietary. Clearly it is sometimes ASCII strings, but a lot is binary data. You're going to have to spend a lot of time correlating the content of the messages with what you see in the user interface and whatever else might be happening to the device at the time.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.