TKJ Electronics

Internet of Things (IoT) is one of the big electronics subjects throughout the world this year.

To show the capabilities of custom IoT devices and to help a local LAN-event organisation, TheBlast, we offered the help to create an Internet enabled soccer table.
Thanks to generous donation by Tuborg Fonden we were able to buy a brand new soccer table for us to modify.

We modified the table by adding two touch displays for user interaction, a barcode scanner for user registration. Inside the table we installed two score detection IR sensors and a ball release system, made by using a motor/wheel from an old Roomba robot. Finally we installed 5 meter of RGB LED strip to light up the playfield.

When scores is detected they are immediately registered online, to be displayed on the LAN-event website, where score timetable and all previous matches can be found.
This post will describe the features of the final table and how it was developed.

PLAYER REGISTRATION

The table itself is just a normal soccer table usually seen in bars and game arcades.

Most soccer tables comes with a coin insert, though we didn’t want our users at the LAN event to pay. Instead we wanted them to scan their name-tag with a unique barcode, handed to them at check-in. This way we could register the users playing and show the names of these on the event homepage.

To scan the barcode we decided to use a UART laser barcode scanner module, WDL3000, from Winson that we could mount in the side of the table. By drilling a grove in the side of the table the users could scan their card by putting it into this slide.

Connection wise the barcode scanner had a connector with the required UART lines, power lines and an enable line so the scanner could be turned in when required.

CONNECTOR BOARD SCHEMATIC
Before going into further details about the features of our IoT soccer table let me first present the connector board schematic which will work as our system design.

SCORE REGISTRATION

One of the main features of an internet enabled soccer table has to be the ability to register the scores online.

To allow this we had to do quite an extensive mechanical modification to the aluminium slides in each end of the table.

By installing either a barrier or object detector sensor in the sides of these slides it would be possible to detect the ball when scoring.

We decided to use a ready-to-use IR object detector sensor found on eBay, with tightening hole mount for easy install, which in general made the installation and connection a lot easier.

With a potentiometer on the back of the sensor the maximum detection distance can be set. Whenever an object comes within the set distance an output pin is pulled low, making it easy to detect the ball with any microprocessor.

BALL RELEASE

Normally for a soccer table without coin-insert the balls would just roll from the aluminium slides straight out to the user again for continuous play.

As we wanted our system to control the amount of balls to be played we had to implement a ball catch-and-release system.

We decided to go the simplest way possible and use a PVC pipe to collect and hold the balls.

To release the balls we installed a spring-enabled wheel with DC motor from an old Roomba vacuum cleaner. By turning the DC motor a ball would spring thru the pipe and out to the player.

On the output side of the pipe an IR object detector would see the ball and indicate the successfulness of a ball release.

RGB LIGHTING

To make the soccer table even better looking in the low lit environment where it would be used most of the time, we installed approximately 4 meter RGB strip on the sides, just below the top glass, and the rest of the 5 meter strip below the table.

We decided to use an LED strip with built in WS2801 controllers to enable individual control of the RGB pixels along the strip.

This made it possible to light up the game field and make cool effects when scoring etc. Furthermore the strip on the bottom added a nice underlit glow effect to the table.

TOUCH INTERACTION

As the users should be able to interact with the table and start a gameplay by scanning their cards, we would need some kind of user interface.

We decided to use two 5.0″ touch displays with a resolution of 800×480 and built in SSD1963 controllers, so we could connect the 16-bit parallel interface to our microprocessor. The displays can be found on eBay here: New 5.0″ 800*480 TFT LCD Module Display Touch Panel + SSD1963 For 51/AVR/STM32

The great thing about this 16-bit 8080-type parallel interface when using multiple displays is that the displays can share more of the the control pins and only need individual Chip Select pins.

For the touch functionality the displays also included the XPT2046 (equivalent to ADS7843) pin-interrupt featured I2C touch driver making it easy to read the touch presses.

We decided to install a display in each end of the table, pointing towards the players on each side. This way the current score could be displayed to the users.

To be able to mount the display and also protect it a bit we manufactured two custom steel brackets that could hold the display into place on top of the wooden bars on the table ends. To get the display cable (40-pin flatcable) thru the table ends, a groove was drilled into the wooden bar of each end.

With silicone and a protective plastic sheet the display was glued into the frame and later screwed onto the table.

CONTROLLER BOARD
As we had decided to use two rather large resolution displays we had to find a processor with enough performance to handle the updates of all the pixels. As a the rergular Arduino wouldn’t give us enough performance we have to go for a larger processor, preferably an embedded one from the ARM Cortex-M family.

My favourite embedded ARM processors has always been the STM32 family especially the STM32F1 (Cortex-M3) series and the STM32F4 (Cortex-M4) series.

I prefer to use these processors as their features are good, price-vs-performance is well and they are well documented with plenty of example projects and libraries. Most important is that the examples and libraries are ready to be used with the Open Source GNU GCC compiler.

Some of the STM32 devices also includes a built-in Ethernet controller to make Ethernet connection easier, only requiring an external Phy.

So I wanted to find a development board featuring a high a performance STM32 device with Ethernet support.

Luckily OLIMEX had just the right board for us, the STM32-E407 featuring an STM32F407ZGT6 running up to 168 MHz with 1MB of Flash, 192KB of SRAM, Ethernet and USB support and plenty of connectors bringing out the GPIO’s.

With plenty of speed and flash size this microprocessor should do well enough for handling the touch displays, registering scores and saving them online.

CUSTOM CONNECTOR PCB

As the OLIMEX board features some smaller 20-pin GPIO connectors the best way to get everything hooked up to the microprocessor board would be to make a connector PCB instead of just breadboard- and jumper-wire it.

After some testing with all the modules and sensors connected with jumper wires to select and confirm the GPIO’s to be used we designed a connector PCB to take in all the individual module and sensor wires and connect them to the matching 20-pin GPIO header.

The final connector board can be seen in the image to the right.

FIRMWARE
Having finished and connected all the hardware it was time to start programming the firmware.

Currenly my favourite IDE for embedded ARM programming featuring the GNU GCC compiler is the CooCox CoIDE so I quickly sat up a project for the STM32F4 device in there and took all the required chip-wise libraries from the ST Standard Peripherals library archive.

I started off by programming and getting the low-level HAL drivers working, such as Displays, Touch, Sensor detection, Ball release, Ethernet etc.

For the Ethernet ST has yet again provided a couple of good examples using the LwIP stack. As we would need our system to contact our server API thru a TCP connection to a PHP script, we had to program a client-wise HTTP connection script, as all of the ST examples were only HTTP webserver based.

To control the LCD display I programmed a custom display driver capable of handling multiple displays writing on either a single display or both at the same time.

Initially the displays were tested with jumper wires to the OLIMEX board which made it possible to active rather high refresh rates by using the FSMC bus of the STM32 processor. Unfortunately the longer cables required to connect the displays from the edge of the table to the connector board in the centre, happened to create a lot of problems. After a lot of troubles and bug-searching I had to completely re-program the low-level display driver part to disable the FSMC use and just drive the 16-bit bus directly and slower. Furthermore we still had some I unexpected noise issues with the displays and cables making them unusable here and then??!

Similarly to the dual display driver I programmed the touch driver to include interrupt-based touch reading from both displays, using individual chip selects for the two touch drivers.

RTOS BASED SYSTEM
After getting the low-level drivers working we started planning all the features of the system including all the tasks it would have to take care of. This made me realise that the system would have to deal with a lot of different tasks simultaneously why a realtime operating system (RTOS) would be beneficial.

To summarize some of the tasks the system ended up includes:

• Queue based HTTP GET task
• GUI system with touch handler
• Barcoder scanner handler
• Score/IR interrupt handler task with ball release
• RGB Strip effect-based handler

Describing all the features of the individual tasks would be quite comprehensive, but feel free to ask questions in the comments or by mail. Instead I will describe the overall idea with the tasks and their interconnection.

A link to the complete project code can be found in the bottom of the post.

When the system is booted the user will be presented with a GUI on the two touch displays where a touch handler will take care of the touch inputs and switch between menus.
In the meantime a task takes care of displaying different effects on the RGB LED strips depending on the currently selected effect that can be changed globally by any task.

When a user is about to start a game the Barcode scanner task is initiates which turns on the scanner and waits for a barcode to be scanned and then save the scanned barcode in a global variable.

This saved barcode is used in the GUI to initiate a HTTP GET request to the server API to register the gameplay. This is done in a queue based manner so the HTTP requests will be processed when a socket is available – as quickly and possible – and at timeouts the request is tried a couple of times before returning an error.

In terms of error handling this way the system is capable of figuring out if it has been disconnected or the API server is down and report the error to the users to avoid non-registered gameplay. Though if the system is disconnected at power-up the system will automatically boot into a freeplay mode where the scores won’t be registered and the users won’t have to scan their card.

Finally when a gameplay has been started the score handler takes care of releasing a ball to the user by watching the ball release IR sensor.

When a score is detected with one I of the score IR sensors the team score will be accordingly updated. Furthermore the RGB strips will also do a running winner effect, where the pixels will move to the end of score with the scoring team color. If the new score is less than the winner score a new ball will be released.

When a team wins by achieving the winner score (normally 10), a winner flag is set by the Score task which the GUI checks and displays the winner menu together with a winner effect on the RGB strips.

FINAL ASSEMBLY AND DEMONSTRATION
Putting everything together, gluing in the sensors and displays and getting everything to work together took quite some time.

After getting everything if assembled there were still a lot of firmware fixes to be made including some slight graphical appearance changes.

Seeing the final result and with the firmware working was a huge pleasure and success.

It has been a long road taking over 6 months from idea to prototype to assembly to final firmware development. It has been great using the STM32 family again and the FreeRTOS system has yet again not let me down – as long as you remember to assign enough RAM/Heap for it 🙂

After a lot of testing the table was put up at the yearly LAN event, The Blast, where it’s appearance was greatly appreciated. The table was used all the time and over 200 registered matches were played throughout the 4-say event.

PROBLEMS AND FUTURE UPGRADES
Getting to the final result of the table has not been without any issues and especially after getting it tested and used for the whole event new issues has also appeared.

As mentioned earlier in the post we had quite some issues with the 40-pin flatcables going to the displays. It seemed it was noise problems due to too long cables (they were from 1-1.5 meter). We solved some of the issues by providing better shielding at the terminating connector on the displays.

After even further noise troubles we tried to solder a decoupling capacitor on the RD line of the display, that was unused so pulled high, but seemed to be affected by noise from the other lines. This seemed to make the display connection a lot more stable without the dropouts we were otherwise experiencing.

Although we did a lot of precautions and debugging with the cables to the displays we still ended up having similar issues when the table was being used at the event. All of a sudden one of the displays on even both of them would stop working and just be flickering. A simple power-reset of the system kept fixing the issue though until it would happen again.

We still have to figure out the proper cause for the these problems, though we have concluded that we should avoid these cable lengths in the future if we are running a fast-speed 16-bit bus in not better shielded cables. A solution would be either better shielding or a dedicated microprocessor on the displays so another communication protocol could be used.

A future upgrade for the table would be to offer different kind of game modes instead such as time based playing or foul if not scoring within a specific amount of time.

Furthermore it would be better to show the scores differently on the two individual displays, as the score is currently shown the exact same way on both of them. To make it different the score of the team on the side of the display could be shown larger than the score of the opponents.

PROJECT SOURCE
The CooCox CoIDE project including all the C sources can be found on our GitHub: https://github.com/TKJElectronics/IoT_Football

The project includes libraries and source codes covered by GPL and BSD licenses, including but not limited to the following:

• FreeRTOS [GPL]
• FatFS [ChaN]
• lwIP [Swedish Institute of Computer Science]
• CMSIS [ARM Limited]
• STM32F4x7_ETH_Driver [STMicroelectronics]
• STM32 Device and Periphiral drivers [STMicroelectronics]

Please feel free to ask any questions either in the comments section below or directly to my mail: thomasj@tkjelectronics.dk