In our project, we use 4 NXT and 5 EV3 bricks. Two of the EV3’s will be connected in daisy chain mode, so we need a grand total of eight connections to the PC application. In our version of 2013, we noticed that more Bluetooth connections results in less reliability. Because of that, our hardware architecture is now based on the NXT bricks to connect to the PC via Bluetooth and the EV3 bricks via WiFi. As mentioned in the previous article, the communication will be done by sending messages back and forth using the mailbox mechanism. By this means, we can create intelligent ‘hardware pieces’, that can handle complex instructions. For example, by sending the string “Uncouple” to a train, the responsible NXT brick will independently handle this instruction and controls the needed actions to uncouple the wagon from the train. The string is read by the Read Message Block, both available in the NXT and EV3 programming environment.
The PC application is responsible for connecting the various hardware parts (delivery station, PUI receiver, crane, etc) and the overall intelligence between these parts. This architecture makes it easy to test the several parts (see also the previous article about the test program) independently and gives more flexibility.
The Bluetooth communication was already implemented both for the NXT and the EV3. All we need is an extension that the EV3 can also communicate over the WiFi connection. That doesn’t sound to difficult. In this article you can read about the ugly truth.
In all documentation about the EV3, it was claimed that WiFi was one of the features of the new brick. So, we assumed that sending messages back and forth from one brick to another would also be possible. It was rather easy to make it possible for Bluetooth, so we didn’t expect that it would be difficult for a wireless connection.
How wrong can you be! As you may have noticed in the programming environment, there is no way to configure the Mailbox programming block from which connection it should read.
So, more advanced programming is probably needed. The next issue that we faced, is that there is not much ‘advanced’ documentation available. The best source for me was the Monobrick library of Anders Søborg. If he can do it, we should be able to do it as well.
So I used the Monobrick library to setup a Bluetooth connection and send some data from the PC application to the EV3. Check, that works. The data was smoothly received by the Mailbox. Change the parameter in the Monobrick connect function to ‘Wifi’ and try again…. and yes, that also works fine. By looking at the Monobrick source code, it was rather easy to setup the connection without the Monobrick library.
The following hypothesis was made: in the Mailbox programming block, it is not necessary to configure the connection type since the only way that two bricks can connect to each other, is by Bluetooth. The WiFi connection is only used to communicate between the programming environment and the EV3. For regular EV3 users, this is true. Based on this hypothesis, I hoped that the firmware programmers built-in a sort of connection hierarchy “always use the fastest connection available when reading mailboxes”. So, if there is a wireless connection available, use that one instead of the slower Bluetooth connection. The hope was also based on the fact that this is true for sending data from the PC to the EV3. That hierarchy would make live easy for us programmers.
Sending data from the PC to the EV3 is based on a so-called System Command WRITEMAILBOX (see screenshot below).
You need to juggle around with these command codes; byte shifting, hex codes and much more but it is doable. Writing the data to a mailbox was therefor relatively simple. The first clue that it might not be so easy to read data, is that the documentation does not refer to a READMAILBOX command. Since documentation is (not almost, or maybe I should say hardly ever) up-to-date, so you should always check the ‘compilable documentation’ : the source code itself ;-).
The EV3 sources are open-source, so I downloaded the C code from the Github repository. I checked the part that is responsible for handling the (mailbox) communication. I found out that in the ‘write’ function, a ‘hardware’ parameter is checked (HW_USB, HW_BT or HW_WIFI). That made sense. In the corresponding ‘read’ function however, this parameter was missing. Would this indeed mean, that it is not possible to send data from the EV3 to the PC application. This could imply a major change for our architecture, as eight simultaneous Bluetooth connections are simply not reliable enough!
I asked Anders from Monobrick if he knew more about this, and he confirmed that it is not possible to send data from the EV3 to the PC application (other then rewriting the firmware). To be really sure, I used a network monitor to see if the brick was sending data at all when using the “Send message” block at the EV3 program. And the network monitor confirmed as well: no data is send when the “Send message” is used.
Now, that is a real programming challenge. Is it really not possible to use a WiFi connection and send data back and forth from the PC to the brick….? Is it really necessary to write our own firmware?
No, we don’t. It is possible to communicate wireless from the EV3 to the PC application. More about this in the next chapter….