Hey everyone, I am back with April’s set of updates - albeit a bit delayed. We have a lot going on in parallel, but lets catch you all up.

Hardware

I.MX95 Design close to completion

We’ve spent almost all of April getting the I.MX95 version of the mainboard to the finish line. We are now 7 days away from releasing to manufacturing. A couple of days, we have received review comments from NXP as well and are working to incorporate them. We have had some surprises lately, but things overall look good-to-go.

Still troubleshooting the WiFi Issue 😢

This one is a bummer. I spoke about the WiFi issue in the last update; we unfortunately don’t have it resolved yet entirely. But we are getting closer to identifying the performance issue with the module. Part of it seems to be linked to Access Point issue, and the other points to behaviour in Power Save/Deep Sleep mode.

We are working closely with the teams at U-Blox and NXP (chipset) to debug the issue. The difficult almost impossible choice we have made right is to go ahead with the I.MX95 EVT with the same module and keep working with the chipset maker and hopefully see a fix in the firmware come out soon.

Breakthrough with the thermal design

Ever since we decided to introduce the I.MX95 processor with the Comet, I have been worrying about its increased thermal requirements. Since 4-6 weeks our mechanical team has been constantly at it, and you can see the progress with each iteration.

These simulations are run with the processor at 4.5W (which is its upper limit) and at 30°C (86°F) ambient.

Eventually we concluded that we just need more space for the heat to spread through. In all previous iterations, the aluminium middle frame was covering mostly the region above the CPU, which led to heat getting concentrated in that area and creating a thermal hotspot.

In the latest (6th) iteration, we’ve extended the middle frame towards the bottom, underneath the battery. This allows heat to spread more evenly across the structure instead of being localized. As a result, we are observing a more uniform temperature distribution and lower temperatures on the back cover, making it more comfortable during heavy use.

Battle Testing the IO Connector

Reliability of the front 40 -pin GPIO connector is something we’re taking very seriously, especially since it’s used frequently to connect extensions.

To properly test this, we’ve built a pogo pin testing jig that simulates repeated connections between the Comet and its extensions. The setup uses a stepper motor with a linear guide mechanism, similar to a 3D printer, to perform consistent plug and unplug cycles.

On the Comet we run a diagnostics script that runs through every interface methodically: GPIO states, UART, both onboard I2C buses, and ADC. The MCU on the extension, running CircuitPython, plays its part on the other side of each test. At the end of the sequence, the script reports a clear PASS or FAIL, and keeps recording logs for tracking across long duration of tests.

The goal here is to understand the long-term behavior of the pogo pins, including connection reliability, failure rates, and expected lifecycle. This testing is helping us identify any weak points early and improve the design before it reaches users.

We do have findings on this, and are working with our Pogo Pin manufacturer and Housing manufacturer for further improvements. More on this in the next update!

Improved Water and Dust Protection -

We’ve made an important change to further improve protection against water, our arch nemesis. The headphone connector has been replaced with a IPX7 connector, which is a significant improvement in terms of sealing.

With this update, all the connectors are waterproof. Even though Comet will not be IP rated, we still plan to test it and offer as much protection as we can to make it more durable and reliable in everyday use.

EMI Emissions Cleared! Ready for Pre-Certification

We recently completed EMI emission testing of the I.MX8M Plus DVT at a test facility. When we tested the EVT in last December we were seeing emissions above permissible limits in certain frequency ranges, particularly between 50 to 200 Hz and around 1 GHz .

Now with the DVT, with the stabilized power delivery and improvements in layout and shielding, the latest test results show that all emissions are now within the required limits. This is a good milestone for us and gives more confidence in the design.

We are now preparing for 3rd party pre-certification to start later in May, we are sending few units to a test facility to perform all regulatory tests to ensure our design can clear region-wise requirements such as FCC, IC, CE.

LTE Development Status

We continue to make progress on the LTE front. Here are key checkpoints we have covered -

• Calling and SMS enabled on EM060K: We are now able to make phone calls and send SMS on the CAT-6 modem we are testing with.
• Determining prices and supply chain: The memory crisis has hit modem prices too, we are trying to strike a balance between performance, certifications and affordability.
• Antenna design in-progress: We have sent two units to Quectel for designing the antennas (hopefully future proofing them for 5G too), they will ship us few samples later this month.

Also we got our audio pipeline working end to end for LTE - the audio quality quite close to what we expect from our everyday smartphones. We still have to fine-tune a bit more, I will share a demo in the next update!

Our current ETA for releasing the Modem add-on on the Hub is by end of this month, we will keep you posted!

Software

We are now on mainline Linux 7.0!

We have managed to get the i.MX8MP working with all of the peripherals on mainline Linux 7.0, some of them work out of the box, some of them needed some patching up, the display was a real blocker.

While we were at it, we ended up fixing a 5 year old bug in the magnetometer iio driver and submitted a patch upstream for the same. Here’s a list of all major peripherals we have working -

And a glimpse of our favourite log :)

You can check out our progress at: https://github.com/mecha-org/linux/tree/mecha-v7.0-wip

In parallel, we are also pushing hard to pair our upstream kernel with upstream bootloader i.e. U-Boot. Later in April we realized that U-boot mainline actually is still missing pieces available in NXP’s downstream U-Boot-imx for the DSI stack, I don’t think it has been pulled off before. Happy to share that after weeks of porting the drivers, just yesterday we finally got the display to work on the mainline u-boot.

We are now closer to our goal for a fully upstream stack from the bootloader to the kernel, reducing dependency on vendor forks and improving long-term support. Next up, we have to get the I.MX95 on the mainline, and start upstreaming all our patches and device trees.

Building the Launcher, a brick at a time

We continue to make progress on the Launcher, over the past 4 weeks - we have spent good time implementing the OpenGL based renderer. Currently the renderer is limited to GLES 2.0 features, while we wait for the full GLES3 support in Mesa (development starts this month). Here are some of the things the renderer can do -

Zero Per-Frame Allocations: Every frame, instead of asking the GPU to create and destroy memory for each button/panel individually, we pack all UI elements into one memory block that's been reserved upfront — and just overwrite it each frame. This saves us from a huge overhead on the GPU driver.

CPU based batching (for now: As of now Etnaviv doesn’t support Instancing (draw many copies at once) feature at the moment . So instead of the GPU repeating a rectangle's shape N times itself, we make the CPU manually copy and expand each rectangle into 6 vertices (2 triangles = 1 quad) and hands the GPU one big flat list — same result, different approach.

Early-Z Depth Sorting: By drawing opaque elements front-to-back first in a two-pass system, the GPU can discard hidden fragments before the fragment shader even runs, saving critical memory bandwidth.

Unified Monochrome Atlas: All icons and text characters are baked into one single grayscale image (1 channel instead of 4) at build time, so the GPU only ever reads one value per pixel instead of four. This also helps in zero format switching — and since there's no color data stored in the texture itself, the GPU uses significantly less memory bandwidth work per frame.

We are open for more optimization ideas 💡. For the I.MX95, we plan to leverage Vulkan as the rendering backend. We will get to it after our EVT is ready.

You can head over here https://github.com/mecha-org/mecha-wayland/tree/unstable to track the progress.

(Re)Building the Native Apps

We’ve started re-building the native apps on the Mecha Comet. While we’re continuing with the same stack (Flutter on embedded Linux), we are approaching them with a more long-term stability and maintainability view -

Strengthening the Foundation: Instead of pushing for feature-heavy apps early on, we’re stepping back and focusing on fundamentals, getting the architecture and structure right. This way future contributors can refer to the native apps as reference implementations.

Research & Direction: We spent time studying existing small-screen interfaces — what works, what fails, and more importantly, why. This has helped us avoid assumptions carried over from larger devices, and build a clearer direction for Comet’s UX from the ground up.

Test, test and re-test: Till earlier this year, we didn’t have stable units to test our software on. With test units available, we are now able to test functionality and usability extensively while developing.

Here are some initial wireframes of some of the apps in development right now. These are mockups, their visual design will follow later this month.

You will find the apps available on https://github.com/mecha-org, we are setting up separate repositories for all the apps.

Supply Chain

We didn’t have much good news to share about this in the last update. But I am happy and relieved to share that we have completed ordering most of our parts, especially the critical ones. Now comes the next harder part, ensuring they all deliver in time 😬.

Here is a quick summary -

Community

Mecha is now on Matrix

We are now available on Matrix(.org) the decentralized open communication platform, with our own homeserver. We have bridging with Discord allows us to stay connected with our broader community without disruption.

Join Mecha on Matrix: https://matrix.mecha.so

Public Roadmap now in works

We've been working on something that we think changes how you interact with the Comet's development - a public community roadmap where you can see what we're building, what's shipped, and most importantly, tell us what you want next.

Some of the features include - submitting your ideas, community voting, commenting. It'll go live in May. Here's a sneak peek at what to expect.

Alternate M.2 LTE Modem for the Comet

The good folks at PCBCupid.com has designed an alternate M.2 LTE Modem for the Mecha Comet. 

You can find more details here, let them know what you think - https://forum.mecha.so/t/m-2-4g-2g-fallback-module-for-mecha-comet-compatible-quectel-alternative/207

What’s upcoming?

We have given ourselves time till June 30 to wrap up all engineering and focus on production and shipping from July to September. Here are are our upcoming milestones -

1. Releasing the I.MX95 EVT for production including PCB Fabrication and PCB Assembly - by end of May
2. Board bring up and testing of peripherals on the I.MX95 EVT - starting from June
3. Mechanical Validation before releasing for production dies - entirety of June
4. Boards
5. Getting the first pre-release version of Mechanix OS ready - June-July

That’s it for now! Thank you for reading and have a great weekend!

May the force be with you,

Shoaib & the Mecha Team

P.S - Don’t forget to update your pledge on the Mecha Hub - https://hub.mecha.so