Bug Report - ASPEP Protocol Ping Packets

[ccut93]

Hello,

I am currently trying to implement an ASPEC Controller in C# to communicate with a motor control dev board over the UART (essentially, creating motor pilot with the ability to modify as needed).  So far, I have implemented Beacon and ping packets.  Beacon packets work perfect.  When I do a ping packet, the return data seems garbled. 

The code is designed to not process any packet that doesn't have a valid header CRC. I tested this by manually corrupting the header, and I no longer saw output from my packet detection, which suggest to me that I am receiving what the devkit is trying to send.

I programmed my code to output debugging information every time a valid packet is sent or received.  I have attached the output of my code.  It starts with 2 pairs of beacon packets to negotiate buffer sizes.  I then start sending 4 ping packets per second with consecutive packet numbers.

For the ping packets, I am expecting to get back the same packet, except for bits 4-11 ( configuration flags and LLID), and bits 28-32 (Header CRC).  Instead, the I get the least significant nibble from the packet number in bits 16-19, and zeros elsewhere within the 16 bit Packet number.

I tried using Motor Pilot to sniff examples of how it behaves with ping packets, but the only ping packets it sends is with packet number 0, which doesn't produce what I am seeing.  Is there a way to force MotorPilot to periodically send Ping packets?

Is this expected behavior, or is something going wrong?

Devboard: B-G473E-ZEST1s
Powerboard: STEVAL-LVLP01
Code Configuration: HSO

[ccut93]

I've found a clue.  If I reset the board without resetting my ASPEP connection, I get the exact same packet back, which would be the expected behavior.  Essentially, this is the same as sending ping packets before sending beacon packets, so the ASPEP is not configured.

[ccut93]

I have identified the cause of this behavior.  It is caused by line 769 of aspep.c, Under the ASPEP_CONNECTED case of ASPEP_RXframeProcess.  Under this case, it reads packetNumber by reading only the second byte of the header.  In other cases, it reads packetNumber as ((packetHeader & 0x0FFFF000U) >> 12U).  By changing the code to the bitmask, I am able to get the behavior described by the documentation.

[cedric H]

Hello @ccut93,

Thanks a lot for sharing your findings.

Indeed, I confirm that in case of CONNECTED State the packet number we send back in a PING packet is wrong and the correct version is as you guessed ((packetHeader & 0x0FFFF000U) >> 12U).

Now, I would like to give you some insights about this packetNumber. When we designed the protocol, we saw it as a way for the controller to measure the time we lost connection. In practice the implementation of the ASPEP in the MC Pilot does not make use of it, and as you saw, the performer doesn't do anything with it. If in the future we want to upgrade the protocol, this packet number field would be the best candidate to save some bits... 

Anyway, we will fix it to be aligned with the documentation for the coming version 6.3.0

Last point, to answer your question : "Is there a way to force MotorPilot to periodically send Ping packets?"

Yes, if you stop polling for registers by unchecking the Radio button "Polling" just next to the Connect button, then the Pilot will send PING packet to guarantee that the board is still connected. (But it does not increment the packet number !)

Regards

Cedric