0
\$\begingroup\$

I have a device (a traffic counter) that communicate with my computer throught Serial Port.

To extract data from this device, I use a specific software. I'm also using a Serial Port Monitor to check what is written on the serial port and what is the serial answer.

So for example if in the software provided with the counter I click on "get power consumption information" my serial monitor capture the following result:

[30/08/2018 18:29:28] Written data (COM4) 
    3f                                                ?                
[30/08/2018 18:29:28] Read data (COM4) 
    3f 20 33 63 20 28 30 38 3a 33 35 20 30 39 2d 30   ? 3c (08:35 09-0 
    37 2d 32 30 31 38 20 29 20 2b 28 4d 3d 35 2e 36   7-2018 ) +(M=5.6 
    38 56 2c 20 52 3d 35 2e 33 37 56 29 0d 0a 35 62   8V, R=5.37V)..5b 
    ...

Then if I send by myself the same Serial command (so ? or 3f in hexadecimal), I obtain the exact same result. Great.

Now I try to extract the stored data. So I click on "extract the stored data" and my serial monitor capture the following result:

[30/08/2018 18:42:46] Written data (COM4) 
    72 30 35 64                                       r05d             
[30/08/2018 18:42:46] Read data (COM4) 
    64 20 02 f4 01 b8 5f aa 81 00 ca 39 2b 4b b8 28   d .ô.¸_ª.Ê9+K¸( 
    dc 98 77 2c 59 ad 19 f6 5b 34 9c c7 31 5e 1f 1e   ܘw,Y­.ö[4œÇ1^.. 
    68 5f c8 8e 7b 32 4f ed 10 60 51 d2 a1 5b 33 62   h_ÈŽ{2Oí.`QÒ¡[3b 
    ...

But this time if I send by myself the same Serial command, the result is totally different !

[30/08/2018 18:41:01] Written data (COM4) 
    72 30 35 64                                       r05d             
[30/08/2018 18:41:01] Read data (COM4) 
    72 20 30 35                                       r 05      

Why the same serial command give me two differents answers ?

If I can get the same answer it will be easy to recreate the file created by the software... but I need the same answer.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Too many unknowns in terms of the device implementation to answer this, but, my first guess is that there is a side effect in terms of "extracting" the data. Maybe the data you "extracted" was over-written after you read it... or, if the device is utilizing a FIFO maybe the pointer has moved to the next yet-to-be-extracted memory location. No idea really, but something to think about. \$\endgroup\$
    – CapnJJ
    Commented Aug 30, 2018 at 16:54
  • \$\begingroup\$ Hello thank you for your suggestion, unfortunately I'm not an eletrical engineer this is certainly why my question is a little bit too broad. I can extract the same data twice, so I know that the memory is not over-written. I going to read some doc about what a FIFO is, then I will come back. \$\endgroup\$
    – obchardon
    Commented Aug 30, 2018 at 17:06
  • \$\begingroup\$ Well, if you have proven you can read the same info twice, the FIFO thing is a "don't care"... it would only be an explanation as to why you could not read the same info twice. I was assuming "get" and "extract" were two different commands, and may behave differently. (i.e side effects of the command) \$\endgroup\$
    – CapnJJ
    Commented Aug 30, 2018 at 18:26

1 Answer 1

1
\$\begingroup\$

A serial interface, even a standard one like RS232, enforces nothing about the application protocol (available commands and their syntax) of a device. Which can have all kinds of special cases and commands that change settings or the way other commands work, limited only by the creativity and/or masochism of the engineer that designed it. This is why the same command can give you different results. Sometimes commands need other commands or conditions to provide results you are looking for.

As a metaphor, on a command prompt on your PC, typing ls will give you a different result if you issue a cd command to change directory in between. This is an illustration of how a command can have a side effect on the output of other commands.

In this particular case, there is something either the application or device is doing that provides valid data in one case but not the other. Or something you are missing in the capture, or even something you physically do to the device (e.g. power cycle, or button press) that you did not account for.

That being, this is simply the "joy" of reverse engineering, figuring out all the little details and side effects. It is impossible for anyone to give you any more information without either providing more information on the device, but even then all we can do is guess unless you can find command documentation or a protocol specification for this device. Sometimes this is provided in a datasheet or manual even if proprietary software is available as well, so it is worth checking.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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