RoadTest: Enroll to Review the Infineon AIROC™ Cloud Connectivity Manager Eval Kit
Author: Galloth
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: N/A
What were the biggest problems encountered?: My biggest issues with this product is that I was able to achieve only slow connectivity between AWS and the CCM. Moreover I was unable to detect missing event in the trasmission.
Detailed Review:
Motivation
I decided to participate in the roadtest of the AIROC CCM evaluation kit because I wanted to gain my first experiences in the area of Internet of Things (IoT) and outsourcing the computation to the AWS cloud.
The topic of IoT is not new but until recently it did not catch my interest. However, with the advent of artificial intelligence, the possibilities of the device connected to the cloud seems to be infinite. We often hear about the robotic factories monitored and controlled from the cloud over the internet. I must admit, that I was hyped up with the advertisements about the CCM showing the robots, drones, etc. Therefore I was interested in the actual possibilities and limitations of such a solution and this roadtest offered me the way to discover exactly that. My original plan was to use this CCM to connect RC car with the AWS cloud system to use the cloud to provide more advanced driving algorithms for the car, such as obstacle detection or the route planning.
IFW956810 description
The IFW956810 is the cloud connection manager development kit. It contains the IFW56810 Cloud connection manager (CCM) together with the FTDI chip for connection between host PC and the CCM. The connection between the FTDI chip and the CCM is realized by the set of jumpers as shown on the following figure.
This solution allows easy switching between different evaluation modes. At first I evaluated the CCM through the python program running on the host PC and later I moved my experiments into the MCU with the hopes to obtain more realistic results. The photo shows the jumpers in the starting position. The DevKit can be connected directly to the PC over the USB-C port. The adapter between USB-A and the USB-C ports is part of the package.
The basic documentation for the SW working with the CCM is available online and is comprehensive enough for the first experiments with the device. The online documentation describes basic AT commands used to send/receive messages as well as how to set up the AWS cloud account to communicate with the DevKit. After a few minutes of online searches, I was able to find a list of AT Commands supported by the CCM as well as an Getting Started document. However, I was never able to find comprehensible documentation describing all supported AT commands or the architecture of the CCM itself.
Python experiments
For my experiments I used a Windows 10 PC. When the IFW956810gets connected over the USB, two new Serial ports appear in the device manager. In my case, the CCM was consistently connected to the second one. (Specifically COM6 on my computer). We can use putty or any other terminal software to connect to this port and send AT commands to verify that connection is working.
Instead of using the terminal, I used python and the pyserial library to facilitate the communication with the CCM. To connect with CCM, I used the following function
The configuration for the serial connection is copied from the User guide and worked on the first try. The CCM supports an ID function to allow it identification over the serial connection. When the AT command AT+CONF? About\n is received, the CCM answers with the string OK Infineon - IFW56810\r\n to confirm its identity. The first experiment I attempted with the CCM was to evaluate the speed and the quality of the communication channel between the CCM and the host PC by requesting identification immediately one after another. The sent AT commands have length of 15 bytes and the expected response has length of 24 bytes. The time module in python allows me to measure the current time. I use a time module to measure how long it takes to send 100 ID requests together with its answer.
From the listed AT commands, only the first three are strictly necessary. The first set the SSID for the WIFI which will be used for the communication with the cloud while the second configures the passphrase for the network. The AT+CONNECT command is described as a command to connect the CCM with the AWS cloud but in my experiments, it was required to connect to the internet after the WIFI credentials changed. I use the AT+DIAG PING 8.8.8.8\n to verify that the internet connection is available. When the CCM receives these commands, it attempts to send the PING towards the specified IP address (google DNS server) and shows the latency as a response. The last command AT+CONF? Endpoint\n just prints the endpoint (specific location in the AWS) to which CCM connects. This information is important when configuring the AWS cloud since if the endpoint in CCM is different from the cloud instance used to run the AWS, the CCM will not connect. This configuration needs to be rerun every time when the WIFI credentials changes but it will remain stored in the non-volatile memory in the CCM.
When the WIFI and Internet connection becomes available, the AWS cloud must be configured to communicate with the CCM. There are several versions of the configuration guide on the internet. The part of the support provided by Infineon to the IFW956810 users is the CIRRENT flow, which can be used to configure the AWS cloud in a few steps. When the configuration is successfully finished, it is possible to send and receive messages between the CCM and the AWS IoT Cloud. The AWS cloud also offers MQTT test client which can be used to send and receive messages as well.
When the device needs to send a message, it starts by configuring the channel by AT+CONF Topic1= command. The IFW956810 allows you to configure several parallel channels. The actual message is sent by AT+SEND1 %s\n command. When the device needs to receive a message, it needs to subscribe to a specific channel by the AT+SUBSCRIBE2 command. The topic for the subscribed channel must be correctly configured in advance. Up to my knowledge, CCM does not have any method to indicate it received a message. The user is expected to call the AT+GET2\n command and parse the response. The MQTT test client may subscribe to receive messages generated by the CCM device and it can be used to generate the message with the topic to which the CCM subscribed. Therefore the MQTT test client can be used to test, if the communication between the CCM and the cloud operates correctly.
With the AWS configured, I attempted to evaluate the reaction time for processing the messages. The first experiment I performed was the loopback test. I implemented a simple lambda function to send back every received message.
def lambda_handler(event, context):
# TODO implement
client = boto3.client('iot-data', region_name='us-west-1')
# Change topic, qos and payload
print(event)
response = client.publish(
topic='/toDevice',
qos=0,
payload=json.dumps(event)
)
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}
On the device part, I run the loopback test function, which sends the message to the AWS and waits for the response message in the /toDevice channel. When the response is received, the test compares the received data with the sent original version. According to the AWS the message size should be up to 128KB. However, the length limit for the message in this test is around 256 bytes.
The latency of this test is very dependent on the quality of the internet connection. I used my home connection for the testing, which may be the cause of the issue, but the average latency for the 1 message loopback was sometimes up to 1.5s.
The second test I did with the CCM was more focused on the speed of sending. I implemented a rule in the AWS to store all incoming messages into the dynamoDB. The database stores the message together with the timestamp when the message was received. Therefore it is possible to send several messages one after another and estimate the network transfer time from the difference between the first and the last timestamp. For this test, the array of different messages of specified length was generated and the transmit channel was prepared. All messages were sent immediately one after another inside the for loop. The only AT command inside the loop was AT+SEND1.
The assumption of this test is that the actual latency of the network is much less than the latency of the CCM and the AWS. As long as the network latency is roughly constant, the results of this test are still relevant. During the test, 100 messages are sent. The time for the test is computed by subtracting the timestamp of the first received messages from the timestamp of the last delivered message. Since the size of the message is known, the payload of the test can be computed by 99*msgLen. The first message is not counted into the payload since it is transferred "before" the first timestamp. I tried to generate messages of a different length to see how the message length affects the behavior of the transport layer.
| Message Length | Average Time per message | Estimated Throughput |
| 50 | 98ms | 0.5KBps |
| 200 | 105ms | 2KBps |
MCU Experiments
The original plan for the RoadTest was to port the python test into some MCU. I selected the ESP32 MCU. Since the IFW956810 connects the FTDI chip and the CCM over the set of jumpers, it is very easy to switch the UART connection from the FTDI towards the MCU. I disconnected the jumpers and connected the ESP32 devkit. Unfortunately I was not able to get a reliable serial connection between the MCU and the CCM. After transferring several AT commands over the serial connection the CCM stopped reacting.
