You obviously don't understand that solving a problem gives you the solution.
So when you want a solution, you want it solved.
Not going to happen.
I have no idea what you just said. Can you stop posting here please? You're not contributing.
You are calling me "uneducated". You have got a lot of nerve.
No, I didn't. I don't know you. I was calling your answer "uneducated", which is was. Take an example from the rest of the people posting here.
As for pessimistic, yes, I am pessimistic, I don't think you have the ability to do this job without help from the manufacturer.
I have nothing to gain by proving to you that I can. Why make it personal? I'm not here for that. Please move along.
@Valeriya, this is not an Arduino problem - I have no idea why you decided to ask for help here. You should be asking for help on some Forum that helps with PC programming problems.
True, it's just that I figured smart people dwell here in general :)
If you want to see what data the device is transmitting try writing a Python program that listens for bytes arriving on the serial port and prints them on the PC screen. (If you don't like Python then use any other PC programming language).
However, if the manufacturers have made any effort to protect their intellectual property the device probably won't do anything unless it gets suitable data from the PC and you don't know what that is.
Yes, I know Python... very interesting solution. I might try that. Thanks :)
Find a data com monitor with recording capability. Put it in the data comm line and set it up to monitor. Then you can review the data stream at you leisure. That is what I did years ago to reverse engineer various protocols to develop a communications front-end processor for mini-computers.
I still have my monitor, but the tape cartridge mechanism died years ago due to the rubber wheels breaking up. Other monitors have other storage schemes. I have a similar monitor at the plant, with no storage, just for cases that needed to view the communications.
Thanks Paul, this seems a bit more complex than the other suggestion but I'll take it into consideration.
This sounds like a fairly easy reverse engineering job, assuming they haven't gone out of their way to make things difficult.
Open up serial monitor (or better yet, a real serial console - I use hTerm). Are you receiving anything? If so, try changing the baud rate on the terminal program until you see something that looks like it might be data. I would probably use this with the hex and ascii representations enabled so I'd have a prayer of seeing the data even if they're sending it as bytes not ascii characters.
If fooling around with serial monitor doesn't show it outputting anything, it stands to reason that some magic incantation needs to be sent down the line to the sensor. So get two serial adapters, and connect TX of one to RX of the other. Open one of them in terminal, and point the sensor software at the other one. Again, you'll need to try different baud rates until you find the right one, but at some baud rate, you'll see the data it sends to start data collection, and now you can send that to it.
If you have to, and the drivers are for a generic serial adapter (eg, FT232, CP2102, CH340G...), you can at least figure out the baud rate for sure by opening it up, finding the data lines (from the pinout diagram for the serial adapter chip) and looking at it with a scope - the duration of each bit tells you the baud rate. (in this case, you could ultimately take the computer out of the cycle entirely by soldering a flying lead onto the appropriate pin and connecting that to the arduino directly)
Great answer :) I would've tried that but yesterday I figured a much easier solution to the problem which is replacing the DC motor with a rotary transducer and reading the torque value directly from that (with an Arduino setup). Of course it's a slightly more expensive solution but I figured I need a new motor anyway.
Thanks a lot everyone!