help with data in, numbers do not look right to me?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I have a USB device that sets up the following physical and logic ranges.

      0x16,0x01,0xFF,    //    Logical Minimum FF01h (-255d)
      0x26,0xFF,0x00,    //    Logical Maximum FFh (255d)
      0x36,0xF0,0xD8,    //    Physical Minimum D8F0h (-10000d)
      0x46,0x10,0x27,    //    Physical Maximum 2710h (10000d)

But I'm not seeing what I expect to see here. From the PC side software I have a graph.

 

 

 

I can set the range from it and it would only make sense for it to range from 0-x or -x to x. but when the data is sent in I see one of the bytes as 0 or 255 and the other as x.  I tried flipping the endian but that made even less sense to me.  Would it make sense to have a sign byte instead of a sign bit? And it seems to be counting down as I hit the center (this is good) but then jumps back to a higher value as it goes past the middle and again counts down. I'd expect it to count up ( with a sign bit). That or gradually counting down from top to bottom.

 

      0x16,0x01,0xFF,    //    Logical Minimum FF01h (-255d)
      0x26,0xFF,0x00,    //    Logical Maximum FFh (255d)
      0x36,0xF0,0xD8,    //    Physical Minimum D8F0h (-10000d)
      0x46,0x10,0x27,    //    Physical Maximum 2710h (10000d)

graph          data0 data1              flipping endian
-------------    0   255 (0x00ff)  255 (0xff00) 65280
-------------    0   172 (0x00AC)  172 (0xac00) 44032
-------------    0    74 (0x004A)   74 (0x4a00) 18944
*************    0     0
-------------    255 171(0xffAC) 65452 (0xacff) 44287
-------------    255 74 (0xff4A) 65354 (0x4aff) 19199
-------------    255 1  (0xff01) 65281 (0x01ff) 511

 

 

 

I created my own PS software and I see the same information. In my software the lowest values I could make was -10000 and 10000 being the highest.

 

//magnitude
                    /*-10000   1 ff  
                     *  -1000 e6 ff
                     *  1000  1a 00
                     * 10000  ff 00  
                     * */

 

 

but I'm still not understating the values I get out. As I go from -10000 towards 0, the data seems to be going up? but the data from 100000 towards 0 counts down. 

 

 

 

This topic has a solution.
Last Edited: Thu. May 6, 2021 - 11:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is not at all clear to me what these "physical and logical ranges" apply to!

 

USB is just a transport mechanism that transports bytes that are given to it. It cares nothing about what these bytes represent.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The best I can tell is physical relates to the PC side (-10,000 to 10,000 ) and logical relates to the Hardware side. If I give the PC the value -10,000 the USB offers two bytes 0x01 0xff, I'm assuming littleEndian.    So I see that as 255 plus a sign bit or -255.  0x1ff. but  -1000 in gives me bytes (0xe6 0xff) and that is where I'm lost. 

 

USB is just a transport mechanism

 Yes and I do agree but the data it is transporting does not make any sense. I Wish Microsoft would have just left at as -10000 but they are stuffing it in to a -255 to 255 range.

 

Perhaps there is some documentation out there on the PID (force feedback)  aspect of USB that makes sense but I have not found any, but to be honest I think the issue is in assembling the bits from the transport as I'm not able to make sense of the data coming in to the USB side. Why would one byte be always be 0xff when negative? I have not seen that before. 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Ok further testing shows its the Microsoft example that is bugged... I found another example online that give me what I expect.

 

-10000 1ff

-5000   180

0      0

500      80

10000   FF

 

So blaming this on crap software I trusted to be correct.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
USB is just a transport mechanism that transports bytes that are given to it. It cares nothing about what these bytes represent.

I'm not sure that's true?

 

USB defines a whole load of Device Classes,  which do associate meanings to bytes - doesn't it ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

True for non COM-port devices. For a COM-port device, USB is data agnostic. The OP did not specify any context other than USB.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I was wrong about the software, they all are producing the same thing.

From the left a Force feedback magnitude is a range from -10,000 to 10,000 but when the transfer to USB takes effect, the input values "supposedly"  range from -255 to 255 in two bytes. Graphing all values on the right, I get this graph below.  If the value is negative the second byte is always 0xff the first ranges from 1 to 255. So I get 0x01ff to 0xffff. 65k is not even within the "logical" range , so confusing.... And when the value is positive the first byte is from 1 to 255 and the second byte is always 0x00. That makes sense. 

 

 

If I use the second byte as a negative flag ( not that that makes any sense) I get this.

 

 

Still complete useless. I could flip the negative value  (255-x) and get this.

 

but that seems so damn stupid...

 

 

 

Last Edited: Wed. May 5, 2021 - 11:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 the PID (force feedback)  aspect of USB that makes sense

 WHAT are you talking about?  USB has nothing to do with PID,...does it?

Are you suffering from solder fumes? Maybe start with an explanation of what you are doing.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

something looks really stupid.

 

trying to squeeze a 10000 number into 255. that means that every step is 39.2 ( not even  a round number)

why not just make the range 255 all together.

 

But then again....

if the number is positive 1 byte is send, but if the number is negative 2 bytes are send....

Why not just always send to bytes? makes reception a whole lot easier, now you always have to look at the next byte received and then hope there never ever is going to be a situation were the byte actually is the negative indicator as then you are screwed up with both numbers not being correct, but also no longer are you in sync with what to receive.

With sending always 2 bytes you can do +/- 32K so way more than the 10K needed.......

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
 WHAT are you talking about?

What, indeed?!

 

start with an explanation of what you are doing.

and  what hardware & software you are using - give links, etc

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:

<snip> the input values "supposedly"  range from -255 to 255 in two bytes. ... 

If the value is negative the second byte is always 0xff the first ranges from 1 to 255. So I get 0x01ff to 0xffff. 65k is not even within the "logical" range , so confusing.... And when the value is positive the first byte is from 1 to 255 and the second byte is always 0x00. That makes sense. 

 

The byte patterns seem like two's complement representation of values in 16 bits (aka signed 16 bit or int16_t):

255 = 0x00FF

1 = 0x0001

0 = 0x0000

-1 = 0xFFFF

-255 = 0xFF01

 

From your description a 16 bit value gets transmitted in little endian format, so the first byte received is the least significant byte of the number while the second byte received is the most significant byte.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

needed to read up on two's complement , thx!

 

PID - Physical Interface Devices

https://www.usb.org/sites/defaul...

 

I didn't think any of that was important to point out, I wanted to focus on the bit representation of what I was looking at. This is an already established implementation, I just needed help with the data from -255 to 255. ccrause seemed to understand what I was confused about.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

now makes more sense!   PID is typically associated with control systems engineering

 

the robot control system undergoes the structure modification. Historically, a list of the force control techniques begins with the conventional PID controllers [1, 2] and continues with more advanced adaptive control methods [3, 4, 5] and robust algorithms

 

A novel constant force feedback mechanism based on fuzzy logic for tapping mode Atomic Force Microscopes (AFM) is proposed in this paper. A mathematical model for characterizing the cantilever-sample interaction subsystem which is nonlinear and contains large uncertainty is first developed. Then, a PID-like fuzzy controller, combing a PD-like fuzzy controller and a PI controller, is designed to regulate the controller efforts and schedule the applied voltage of the Z-axis of the piezoelectric tube scanner to maintain a constant tip-sample interaction force during sample-scanning. Using the PID-like fuzzy controller allows the cantilever tip to track

 

& you say you have a physical device (but never say what it is)--could be a robot arm

 

I have a USB device that sets up the following physical and logic ranges

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!