[With Technical Conformity Mark] Utilizing a Ultra-Cheap Bluetooth Analog Stick Controller

2026-08-30

When trying to operate an mBot obtained through parallel import, it turned out that the Bluetooth module lacked the Technical Conformity Mark (Giteki), potentially violating Japan’s Radio Act. Therefore, we attempted to build a DIY “mBot-like" robot based on the Raspberry Pi Zero W, controlled by a Bluetooth controller bearing the Technical Conformity Mark. This article introduces the background and troubleshooting methods.

The Technical Conformity Mark Issue with the Purchased mBot

• The parallel-imported mBot unit lacked the Technical Conformity Mark on its Bluetooth module.
• Using wireless equipment within Japan requires the Technical Standards Conformity Certification (Giteki).
• Continuing to use it as-is would violate the Radio Act, so we considered safer alternatives.

Building a DIY “mBot-like" Robot with Raspberry Pi Zero W

• Since the Raspberry Pi Zero W comes with domestically certified Technical Conformity Marks, wireless communication can be used with peace of mind.
• We built a base system using Python + GPIO for motor control and accepting commands via Bluetooth.

Selecting a Bluetooth Controller

• Looking for a controller with an analog stick that has the Technical Conformity Mark, we focused on ELECOM’s VR Remote Control.
• Despite being in the lowest price range, it is equipped with a D-pad, A/B/X/Y buttons, and an analog stick, offering excellent cost performance.
• While Bluetooth controllers for gaming generally cost around 3,000 yen, the ELECOM VR Remote Control with an analog stick available for about 1,000 yen is a great deal.

ELECOM VR Remote Controller for Android Smartphones/Tablets Bluetooth Smartphone [Android 5.0 or later] JC-XR05BK Black

Connection Verification of the ELECOM VR Remote Control

Behavior During Initial Pairing

• Performing pairing via bluetoothctl generated the following device nodes:
  • /dev/input/event1
  • /dev/input/event2
  • /dev/input/event3
  /dev/input/js0
  • /dev/input/mouse0
• Among these, the analog stick axis values could be obtained from /dev/input/event2, allowing us to map them and freely operate the robot.

Issues Upon Reboot and Automatic Reconnection

• After turning the remote off and on again, allowing it to automatically reconnect resulted in only /dev/input/event1 being generated.
• Consequently, no analog stick input could be obtained at all.

Cause and Temporary Countermeasure

• We confirmed that Bluetooth profile caches affect reconnection, preventing the necessary HID nodes from being restored.
• Troubleshooting steps:
  1. Remove the target device using bluetoothctl before automatic reconnection.
  2. Delete the entire cache directory:

     sudo rm -rf /var/lib/bluetooth/<RPI側のMAC>/cache/<ELECOM側のMAC>

  3. Pair again using bluetoothctl.
• This outputs /dev/input/event2 just like the first time, restoring analog stick control.

Future Challenges

• We are exploring a mechanism to eliminate the need for cache deletion even during automatic reconnection.
• We plan to verify whether reviewing udev rules and Bluetooth profile settings can bring up event2 without re-pairing.

Conclusion

As an alternative to the parallel-imported mBot without the Technical Conformity Mark, combining a Raspberry Pi Zero W with the Technical Conformity Mark and the ELECOM VR Remote Control allowed us to safely and inexpensively operate a DIY robot. Meanwhile, the issue of HID node restoration during automatic reconnection is bypassed by deleting the cache. Moving forward, we will work on improving reconnection reliability to aim for a more user-friendly system.