RX-Modulus (Completely Modular Mouse)

Overall Progress:

Certainly not far off from the production version now. All of the activates remaining are firmware features to improve the product. So when launched it will have a rich feature set.  

Core Unit:

Basic-Click & Touch-D Modules:

SMART Scroll Module:

Wired Adaptive Interface Module:

Sensor Module:

As there is certainly not enough space on the project page gallery how are the current pictures of the prototype RX-Modulus Project. Internal pictures and breakdowns can be found in the following: Here

Now without further ado, let me introduce you to the RX-Modulus Prototype. 

With Shell Elements:

No Shells:

All ready to go:

Its time to talk about cost.

Throughout development of this project, my objective has been to create something innovative that will improve the quality of life for everyone in order to realistically make my project available to any who will benefit, With that said I prioritized affordability and functionality. 

To get an idea of many many parts makeup the RX-Modulus system I would like have a look at the detailed Components List with Exploded Assemblies

Initial estimates for pricing at different quantities. These prices will hopefully reduce when optimizing/redesigning the current design for production.

Basic-Click Module:

Touch-D Module:

SMART Scroll Module:

Wired Adaptive Interface Module:

Side Button Module: (With Side Base Connector)

Sensor Module:

Core Unit: (With production Core Interface PWA)

Panel Set (Method of manufacture to be chosen)

Pricing up example:

3x Basic-Click, 1x SMART Scroll, 1x Sensor Module and 1x Core unit could cost: (The shells are 3D printed by the user in this example)

The RX-modulus can be configurated and updated the suit the users budget and requirements. The price may seem on the high side but to introduce a quality product to the market with a high level of  responsive support. The sale price must be at least somewhat higher than the raw manufacturing cost. This cost will also cover ongoing development/improvements to both hardware and software, which enriches the RX-Modulus ecosystem.

Of course there is another method we could use to make each element of the project cheaper and that is to offer the users chosen configuration as a kit which they can fully assemble. Just like some of the 3D printers on the market. Just like hardware on the market today products must be made in the thousands to achieve a respectable price.

The time has come to discuss how to go from prototype to the production version.

Plastic/Resin Parts:

At the moment all the prototype parts have been 3d printed in both ABS plastic and resin. For the production version there are a few ways we could go:

1. Keep the parts 3D printed
1. This lets us make small changes without manufacturing an new mould.
2. Lets users print spare parts if broken.
2. Parts injection moulded
1. An element of redesign would have to be done to make the 3D printed parts injection friendly
2. This will certainly decrease part cost of Qty of 1000.
3. Hybrid design
1. Have all Major parts injection moulded that won't be changed in the future.
2. Have all other parts 3D printed, on a industrial scale. 

While we mature this design to the production level we will have a better idea of which method to take.

Mechanical Parts: 

All machinal parts apart from the custom scroll wheel and core unit base are available off the shelf. When we change version we will look at decreasing the brass insert and screw count and use other techniques. This should make the unit cheaper and easier to manufacture 

PCBs:

At the moment all module PCB's have been optimised for manufacture and can be manufactured in batches for about £10 each which certainly isn't bad for 4 layers 0.8mm thick double side SMD boards. There is only one board that requires redesign to production level and that is the Dev Interface board.

Now currently this board is a 6 layers 1.6mm thick double side SMD boards and is designed to be a development board that features lots of debug and monitoring circuits. Because of this and the fact it's 6 layers this is probably the most expensive board of the project at around £70 for a batch of 5. After the prototyping stage we will be designed a low cost production version that still has the same level of protection. The key will be to made it 4 layers which instantly reduces the price and allows this PWA to be made in standard pools. 

It's certainly been awhile since the last shell update log but the first shell has finally been designed and printed. To give you some background this is what the draft shell looked like:

First Draft Shell:

Prototype Shell:

Now I can present the new shell for our project:

Certainly looks alot different from the draft but I'm very hand with our first of many shells.

How was this Designed:

It all started from a lovely piece of concept art, Namely this one.

We then took this concert and started in Fusion 360 with the Bare Frame. 

Sad to say using the free-form tools in fusion is slow and painful. So we decided to do the shell development in Blender. Which is much better suited to this task and a couple days later we had this:

With that done it's time for some good old real life testing and analysis.

Analysis:

Like most things there is a big difference between looking good on the screen and how it feels. So about after 15 hours of printing from both the FDM and resin printers we have a shell the test.  

For the testing we showed and got friends and family to try the shell (I would of used to bigger pool but due to Covid 19 restrictions the pool was limited) the following areas are reviewed 1) Hand Size, 2) Feel, 3) Look, 4) Number of Parts and finally 5) Price. We come to the following outcome for this shell:

Turns out this shell is a great choice for a person with a large hand. The reason for this is actually because of one piece, namely the thumb frame.

As this part comes away from the core body its actively positions your hand to the left. If you have a large hand this isn't an issue as your hand is large enough to accommodate. But for smaller hands it means the device can't be handled at it's best. This is a great start and with the shell in Blender we can made versions for smaller hands and start our shell community. 

This project has certainly evolved over the course of this project and there is quite a few story's I could tell you. Rather than attempt to describe with multiple project logs detailing each step of the design process and the decision tree that has led to the design today, I dug around in a few of my boxes and found a pile of old parts and selected a few to create visual demonstration in the form of a timeline.

Some might look very similar and some look very different but it's all progress for this project.

You my notice the larger PCB at the top middle, these were the first multi touch sense PWA that I designed and made. They were for the first prototypes of the Touch modules (The Touch-D came from the evolution from using multitouch PWA's to touch screen displays.)

To give you some perspective:

This was probably the most mind bending part of the project as there are many ways to handle USB HID incorporation. But for this project it's all about taking baby steps.

Stage 1: Get the Example Mouse HID working.

This was probably the easiest part as the STM32CubeMX automatically generates a USB mouse HID type when select "Human Interface Device Class" in the Class For FS IP in the Middleware-USB_Device tab. All we needed to do was add "RX-Modulus HID" to the 'PRODUCT_STRING(Product Identifier). Once the code is generated and built in the Cube-IDE environment we just needed to plug our mouse into the USB port of our PC and deploy our code. 

Looking on the control panel under "Bluetooth & other devices" we can see that the computer happy recognizes our project as a mouse interface. Now we could have stopped here but the project would just be a common mouse if no special keys or functions. To go further we moved to stage 2.

Stage 2: USB HID Collection

This is where it gets tricky but luckily I found these great websites that really helped:

https://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/

https://notes.iopush.net/custom-usb-hid-device-descriptor-media-keyboard/

There are commonly three methods of combining USB devices together namely:

1. Multiple TLC(Top-Level Collection)
   1. Collections can be used to organize your data, for example, a keyboard may have a built-in touchpad, then the data for the keyboard should be kept in one application collection while the touchpad data is kept in another. We can assign an “Report ID” to each collection, which I will show you later.
2. Composite Device
   1. Uses the same interfacing framework that all HID devices use, which is based in exchanging data with the host through “reports” via  “endpoints”. Each device added will require it's own start and end point.
3. Custom HID
   1. Basically a peripheral that does not fit any of the common device definitions that conform the HID standard (Mouse, Keyboard, Gamepad, Webcam, etc) but still use the same interfacing framework that all HID devices use, which is based in exchanging data with the host through “reports” via  “endpoints”. With custom HID devices the operating system doesn’t know what their function is, but it does knows how to speak with them since they comply with the HID specification. They are normally highly-specific hardware devices that require special software and vendor-provided tools to interact with them.

For this project we decided to use a TLC HID type to achieve a good starting point for our project.

For this test we used the following descriptor:

__ALIGN_BEGIN static uint8_t HID_MOUSE_ReportDesc[HID_MOUSE_REPORT_DESC_SIZE] __ALIGN_END = {
//50 bytes
		0x05, 0x01, /* Usage Page (Generic Desktop)             */
	0x09, 0x02, /* Usage (Mouse)                            */
	0xA1, 0x01, /* Collection (Application)                 */
	0x09, 0x01, /*  Usage (Pointer)                         */
	0xA1, 0x00, /*  Collection (Physical)                   */
	0x85, 0x01,  /*   Report ID  */
	0x05, 0x09, /*      Usage Page (Buttons)                */
	0x19, 0x01, /*      Usage Minimum (01)                  */
	0x29, 0x03, /*      Usage Maximum (03)                  */
	0x15, 0x00, /*      Logical Minimum (0)                 */
	0x25, 0x01, /*      Logical Maximum (0)                 */
	0x95, 0x03, /*      Report Count (3)                    */
	0x75, 0x01, /*      Report Size (1)                     */
	0x81, 0x02, /*      Input (Data, Variable, Absolute)    */
	0x95, 0x01, /*      Report Count (1)                    */
	0x75, 0x05, /*      Report Size (5)                     */
	0x81, 0x01, /*      Input (Constant)    ;5 bit padding  */
	0x05, 0x01, /*      Usage Page (Generic Desktop)        */
	0x09, 0x30, /*      Usage (X)                           */
	0x09, 0x31, /*      Usage (Y)                           */
	0x15, 0x81, /*      Logical Minimum (-127)              */
	0x25, 0x7F, /*      Logical Maximum (127)               */
	0x75, 0x08, /*      Report Size (8)                     */
	0x95, 0x02, /*      Report Count (2)                    */
	0x81, 0x06, /*      Input (Data, Variable, Relative)    */
	0xC0, 0xC0,/* End Collection,End Collection            */

	//78 bytes
	0x09, 0x06,        // Usage (Keyboard)
	0xA1, 0x01,        // Collection (Application)
	0x85, 0x02,        //   Report ID (2)
	0x05, 0x07,        //   Usage Page (Kbrd/Keypad)
	0x75, 0x01,        //   Report Size (1)
	0x95, 0x08,        //   Report Count (8)
	0x19, 0xE0,        //   Usage Minimum (0xE0)
	0x29, 0xE7,        //   Usage Maximum (0xE7)
	0x15, 0x00,        //   Logical Minimum (0)
	0x25, 0x01,        //   Logical Maximum (1)
	0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
	0x95, 0x03,        //   Report Count (3)
	0x75, 0x08,        //   Report Size (8)
	0x15, 0x00,        //   Logical Minimum (0)
	0x25, 0x64,        //   Logical Maximum (100)
	0x05, 0x07,        //   Usage Page (Kbrd/Keypad)
	0x19, 0x00,        //   Usage Minimum (0x00)
	0x29, 0x65,        //   Usage Maximum (0x65)
	0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
	0xC0,              // End Collection
	0x05, 0x0C,        // Usage Page (Consumer)
	0x09, 0x01,        // Usage (Consumer Control)
	0xA1, 0x01,        // Collection (Application)
	0x85, 0x03,        //   Report ID (3)
	0x05, 0x0C,        //   Usage Page (Consumer)
	0x15, 0x00,        //   Logical Minimum (0)
	0x25, 0x01,        //   Logical Maximum (1)
	0x75, 0x01,        //   Report Size (1)
	0x95, 0x08,        //   Report Count (8)
	0x09, 0xB5,        //   Usage (Scan Next Track)
	0x09, 0xB6,        //   Usage (Scan Previous Track)
	0x09, 0xB7,        //   Usage (Stop)
	0x09, 0xB8,        //   Usage (Eject)
	0x09, 0xCD,        //   Usage (Play/Pause)
	0x09, 0xE2,        //   Usage (Mute)
	0x09, 0xE9,        //   Usage (Volume Increment)
	0x09, 0xEA,        //   Usage (Volume Decrement)
	0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
	0xC0,
};

This descriptor basically adds the following HID's stacks with a report number to help the host know there are multiple devices. (Report ID 1) Mouse, (Report ID 2) Keyboard, (Report ID 3) Keyboard media keys. As we have 128 bytes of information in our new collection its very important the "HID_MOUSE_REPORT_DESC_SIZE" to 128 from the 50 bytes the standard mouse HID used.  

#define HID_MOUSE_REPORT_DESC_SIZE                 128U // Was 50

This tells the host computer how much data its expecting to receive.

We just need to compile, build and deploy the code. Once running we once again check the control panel.

Success the computer recognizes our USB HID collection. At the moment we are using three device HIDs but in the not so distance future we will be incorporating more for the up and coming Joystick module. 

Now sending useful data to the host computer is actually very easy, especially if you use 'struct' to organize the data. Below are the 'struct' for each HID collection used. You will notice the first line on each struct is the 'id' used. This matches the descriptor table.

// HID Mouse
          struct mouseHID_t mouseHID;
	  mouseHID.id = 1;
	  mouseHID.buttons = 0;
	  mouseHID.x = 0;
	  mouseHID.y = 0;
	  mouseHID.wheel = 0;

// HID Keyboard
	       struct keyboardHID_t {
	       uint8_t id;
	       uint8_t modifiers;
	       uint8_t key1;
	       uint8_t key2;
	       uint8_t key3;
	   };
	   struct keyboardHID_t keyboardHID;
	   keyboardHID.id = 2;
	   keyboardHID.modifiers = 0;
	   keyboardHID.key1 = 0;
	   keyboardHID.key2 = 0;
	   keyboardHID.key3 = 0;
	   
// HID Media
	   struct mediaHID_t {
	     uint8_t id;
	     uint8_t keys;
	   };
	   struct mediaHID_t mediaHID;
	   mediaHID.id = 3;
	   mediaHID.keys = 0;

 As an example if you wanted the mouse to move is the X axis by 10 units you just need to write the following in the main loop:

// Send HID report
    mouseHID.x = 10;
    USBD_HID_SendReport(&hUsbDeviceFS, &mouseHID, sizeof(struct 
    mouseHID_t));
    HAL_Delay(1000);

 Each compiled, built and deployed the mouse cursers will move right every 1 second.

This is a good summery of what has been done to achieve a working HID interface for this project. The real code is currently in development with all the code functions working as expected from a mouse/keyboard hybrid. We are constantly writing more functions to increase the feature set of our project. More code will be available after the contest finals deadline. 

After fault finding and fixing the Dev Interface PWA, the testing of the RX-Modulus doesn't involve that might in terms of equipment. You just require a PC and a STLINK V3 Mini. The image below shows everything you need and even showing the short term fix from the earlier post.

The first and probably most criteria task was to try the USB interface. To help with the configuration of the STM32 core used we started with STM32CubeMX. Now I cannot tell you how amazingly useful this software package is.

The most useful features are:

• Allows to easy pin defines and setup
• Shows any pin conflicts that are normally hidden in datasheet pin tables.
• Highlights features that cannot be used if certain pins are used.
• Easy code generation to open in Cube IDE or Keil MDK.

The incorporation of STM32CubeMX is really recommended at the beginning stages of the circuit schematic stages. This give you a good starting point to achieve a right first time prototype. In the next post I'll be talking about the USB HID stack and how I achieved a working USB HID Collection.

It's certainly been awhile from my last project log to now but I assure you there has been quite a lot of progress on the project since the last log. The next project log's with being you up to speed.

High-P Core & Dev Interface PWA:

What was my setup for firmware development and testing?

Most of the modules use the same elements for testing which are the following:

1. Digital Discovery Signal Analyser+ leads
2. STLINK V3 Mini

Unlike the ST-LinkV2 the V3 features Virtual COM port (VCP) specific features:

• 3 to 3.6 V application voltage support on the UART interface and 5 V tolerant inputs
• VCP frequency up to 15 MHz
• Available on STDC14 debug connector (Which is designed to the High-P Core)

This is very handy to quickly send out serial data for fast debugging. This also saves desk space as you don't to use another tool namely a RS232 to USB cable. As the debugger is using interfacing via JTAG will still have the opportunity to look a specific registers while debugging. 

Initial Test Results:

Fail: No 3.3V supply at the High-P Core.

Cause of Failure: 

Misalignment of Regulator "REG1" not that you can tell from looking at the board. For this we need to look at the layout.

Just to given you some perspective each pad in 0.25mmX0.45mm with a pitch spacing of 0.5mm. Given the very small pads it's easy to have connection issues when using solder paste and a stencil and placing components by hand or by SMD parts stencils. This IC is ideally suited for PnP placement.  

Short Term Solution: 

Due to the looming deadline of this contest we had no time a re-spin a new PWA to solve this problem. The short term solution was to remove "REG1" and wire in R-783.3-0.5 Switching regulator module to convert the USB 5V to a usage system voltage of 3.3V. This fixed the issue and allowed us to continue development.

Permanent Solution: 

With the short solution sorted I had a few 30 minutes to sort-out the permanent solution that will be using on the Version 2 Dev Interface PWA and the 'to-be' designed lower cost production Interface PWA. The permanent solution will be departing from the ADP7156ACPZ-3.3-R7 Linear regulator to use the LT8608EMSE#PBF Switch mode regulator. This change increases the energy efficiency and also comes in a friendly 10-Lead Plastic MSOP package. The circuit was simulated using LTspice to monitor and reduce the output ripple.

Luckily for us this was the only fault on the Dev Interface PWA. After that both the High-P Core & Dev Interface PWA continued to worked with no problems. Not bad I must say.

Well I'm one happy guy the Adaptive Interface Module has been designed, assembled and tested without any issues or board mods. So lets start off the project log story with the following:

How did I assemble the double sided boards?

Whole I don't have a PnP machine (yet) I've been assembling the boards by hand with some help of a solder stencil, a reflow oven and finally a SMD stencil (which I discussed in a earlier post).

Now some of you might be wondering how I soldered both sides using solder paste.Normally in mass manufacture they would use epoxy glue dots to hold down components during double sided manufacture. But this a costly and takes time. There is another method that can be used which is great for prototyping and it simply uses two different reflow temperature solder pastes.

To assemble the PWA the following equipment and tools are required:

1. Bare PWA.
2. Solder Stencil.
3. Solder Paste distribution (Any card will do) 
4. ESD Strap and ESD Mat.
5. ESD Tweezers.
6. Reflow Oven (Home made or commercial version)
7. Solder Paste (See below)
8. A Steady Hand (Tea or Coffee might be required)
9. Optional SMD stencil for QFN packages.

A view of the finished boards are below:

Solder Paste Tip for Double Sided Assembly:

My tip for assembling a double side PWA's is to use two different solder paste's. My go to choices are:

• TS391AX > Reflow Temp= 235c
• TS391LT10 > Reflow Temp= 165c

The idea is that you with first use the higher temperature solder paste on the less critical comportment side, which in my case was the top side. After reflowed these parts will remain in place during the last pass using the lower temp solder. which was applied to the bottom side. After this you will have a nice double sided assembled board.

Ready For Module Assembly:

After PWA assembly the debug UART wires were connected to aid in firmware writing and testing. All that was left is to screw the module frame into the PWA and the module is ready for firmware development.

What was my setup for firmware development and testing?

Most of the modules use the same elements for testing which are the following:

1. Digital Discovery Signal Analyser+ leads
2. Jlink EDU Mini 
3. RX-Modules Debug Station

The completely test the adaptive interface the following extra are required:

1. 3.5mm 4 Pole Audio Cable to flying leads.
2. Simple Push Button
3. Joystick, 10K Pot Version

Firmware Test Results: Pass with flying colours and fully supports Microsoft adaptive controls and any open source controls. A full specification will be written.

Progress:

Currently in Full Firmware Development.

What's Next?

As the Adaptive Interface Module has passed both hardware and firmware testing the following can be sent for manufacture:

• Touch-D Module Core.
• SMART Scroll Core.

Both these core's share common circuity and routing to the Adaptive Interface Module Core.

Apart from that the following are due to be assembled in the next couple of days:

• High-P Core
• Dev Interface PWA

Keep watching the project logs for more exciting news.

All the Best.