AMC1280USB Firmware v3.0 release

Not applicable - do not use

***9/21/2018***New Firmware Revision 2a link!

Hello,

I finally release a new firmware that fixes a long evading issue with the motion data that on random times could get corrupt and make the motors "kick" a little bit. This major fix will require change of the transmission string ID as well, so for this version I added a new menu that allows the selection between the new ID method and the old ID method, for compatibility with older versions of motion software as well. This option is now under the "Serial ID Format" menu, and you can select between the new "FF FF" ID (Bytes 255,255) and the old "41 42" ID (Bytes 65,66 or Char A,B).


Below are the links to download the bootloader utility and the new firmware:

Firmware bootloader utility
https://www.dropbox.com/sh/n2owe6yo5jon440/AAC5GsAmzcYsnWpdb2j73P23a?dl=0

AMC1280USB Firmware v3.0 rev2a):

https://www.dropbox.com/s/m6lptunco0nl1v3/enc_6dof_AMC1280USB_v3.0_rev2a.hex?dl=0

See this video for instructions on how to update the firmware if you haven't done before, and to see in the end of the video where is the new ID option.

( or use the link to open in full screen: https://www.youtube.com/watch?v=DWRcoQgQ-GA )

If you want to know a little more about the new communication protocol changes and why, keep reading...

The AMC1280USB data protocol is basically two ID characters followed by the 16bit values for position for each axis. If you use less axis, set the number of axis on the controller (i.e. 2DOF) and send only two 16bit position values.

The ID characters used to be "AB" (0x41,0x42) until now, but going forward the ID will be 255,255 byte values (0xFF,0xFF). This change was done to fix a long time appearance of noise data in the transmission, that was hard to identify and debug. The new ID gives solid recognition of the data incoming stream from the computer, allowing for even faster data rates with no false package counts.

16-bit data format in my 6DOF controller is:

ID b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12     (no need for CR as I count the incoming data)

ID  - start of data identifier for the receiving micro controller
byte1 - 8 bit binary number giving act1 demand MSB
byte2 - 8 bit binary number giving act1 demand LSB       

byte3 - 8 bit binary number giving act2 demand MSB
byte4 - 8 bit binary number giving act2 demand LSB

byte5 - 8 bit binary number giving act3 demand MSB
byte6 - 8 bit binary number giving act3 demand LSB

byte7 - 8 bit binary number giving act4 demand MSB
byte8 - 8 bit binary number giving act4 demand LSB

byte9 - 8 bit binary number giving act5 demand MSB
byte10 - 8 bit binary number giving act5 demand LSB

byte11 - 8 bit binary number giving act6 demand MSB
byte12 - 8 bit binary number giving act6 demand LSB

There is no need to send CR or LF character after each data set, in fact not doing so, will have better performance.

The delay before sending new data packet can be as low as 2ms

To assemble the received bytes, I add the two bytes to form a 16-bit value (for 0 to 65535 range, with 32512 mid position) like this:
act1word = act1high
Shift act1word , Left , 8
act1word = act1word + act1low

where
act1word is word type (65535)
act1high is byte type
act1low is byte type



Thanos
San Diego, California  2018