Hey everyone, I am back with August’s updates. We have had busy last 4-5 weeks; we got off track but the good news, we have signed off on the design, it took us longer than we anticipated. I will breakdown everything that has happened and get you all synched up with our progress and next steps.

Before we start, I want to apologize for the delayed update. For the things we have on our plate right now, we are literally trying to make every single day count. I will increase the frequency of these updates as my bandwidth opens up further in coming weeks 🤞.

You can also join our Discord Server or connect on Matrix - we share a lot of tiny updates during the month on the channels. You can also ping me for any questions.

Hardware

I.MX95 Boards are ready, and now in-testing

This has been a long wait, getting a first revision PCB out of the gate is always tough. After we freeze up the PCB design in sync with the mechanicals - begins the dance of getting it actually printed and assembled. Our fabricated PCB finally arrived on Aug 21, but then our processors weren’t here yet so we couldn’t start the assembly. Here are the bare printed PCBs, I always love

Finally, by 31 Aug-1 Sep, we got the boards assembled at the SMT factory. here are some clips of the assembly process if you are curious.

🔈This is the primary pick-n-place process, where the components are soldered on the board.

Overall process → applying solder paste, pick-n-place, automatic optical inspection and X-ray testing 

Here are the assembled boards, in all their glory 🎉

Bring-up (testing) in Progress

The next most important step for us is to get these boards up and running (bring-up), we’ve started this activity a couple of days back. Here is our high-level breakdown on the testing.

We’ve already tested with the official EVKs, so once the critical ones (🔥) are completed we will be able to move faster. Our goal is to finish this list off within this month, it is ambitious but we are prepared.

Our Adventures in Cellular Antenna Design

Remember we have been tracking the LTE Antenna Design part of the Comet’s design over the last two updates? Since late in May, we were working with an antenna design team and based on their advice making changes to the Comet’s enclosure - ensuring we balance thermals and emissions requirements.

By the end of July, we unfortunately hit a dead-end with the design. After a series of simulations, intense discussions - we could no longer find a way to fit antennas inside that could get us the kind of cellular performance we would need in the constraints we had from mechanical and PCB design point of view.

It all boiled down to three primary requirements (i) The antennas have to be perpendicular to the ground plane (ii) Stripping off ALL THE METAL from the 3D space near the antenna (keep-out) (iii) Position that gives the hemispherical view of space. Our previous design could not meet any of these, so the design was compromised on all points.

Back to the drawing board

We didn’t want to get this wrong and regret later. The Comet’s design remains foundational to us for a number of years as we evolve the platform, so we went back to the drawing board with the design team. After 4 weeks of all-hell-broke-loose of PCB + Mechanical + Antenna design, we finally have a solution that resolves all the issues and we finally now have a workable antenna design that can promise adequate antenna performance.

The blue antenna brackets are added; these will house the Flex PCB for the LTE primary and diversity+GNSS antennas.

We have completed all these changes from PCB and Mechanical point-of-view and the antennas brackets and are now in final validation.

This activity has been truly enlightening to us, we have grossly under-estimated the complexities in mechanical and PCB design for building efficient cellular antennas. No wonder RF design is referred as black magic, here is a quick intro) if you are interested to learn more. Antenna design can never be an after-thought, we have to plan this way ahead in the product development, hard lesson learnt. I am sure RF designers reading this are smiling now 🥲.

LTE+GNSS Add-on availability schedule

I am sure after reading this it would be pretty much clear why we were holding back LTE Add-on’s availability until now. We of course remained resolute on offering LTE, but we wanted to ensure full transparency and not make promises in the air.

LTE will be offered on the Comet in the following ways -

1. Standard SKU: The standard / base SKU of the Comet will come with standard plastic brackets with no antenna and no modem mounted in the Comet. Users can buy the upgrade kit in the future and enable LTE support for their Comet.
2. LTE Upgrade Kit (without modem): Users can opt for LTE upgrade kit without modem, the antennas brackets and RF coax cables will be pre-assembled, user can bring their own compatible modem. This will be offered in all countries we ship to.
3. LTE Upgrade Kit (with modem): We will be offering the LTE upgrade kit pre-assembled with modem (Quectel EM060K-GL, voice enabled) to these regions only due to regulatory constraints: (i) 🇺🇸 US (ii) 🇨🇦 CA (iii) 🇪🇺 EU (iv) 🇬🇧 UK (v) 🇮🇳 IN . For 🇦🇺 Aus / 🇳🇿 NZ / 🇯🇵 JP we are still evaluating from regulatory and carrier point-of-view - if you can help in testing in these regions, drop us a line at support[at]mechasystems.com.

I am answering some frequently asked questions here -

Does the modem support VoLTE? Yes, it does, tested with India carriers. We are testing other regions too. But again Comet can be a smartphone replacement if you are willing to make serious concessions. Linux-based phones still have a lot to catch-up.

Is GNSS supported? Yes, L1 GNSS is supported.

Is E-SIM supported? The modem we are using does have an eSIM capable variant, but we have currently not opted for it due to supply chain shortage. Also adding eSIM needs a lot of enablement on the software front as well. Sometime next year we will test the Modem’s eSIM variant and make it available.

Will Data work? Data is going to work in all regions the modem is certified for.

Will Comet undergo carrier certifications? We have no plans to get device certification done with carriers.

Will the modem support VoLTE for my carrier? Can’t be sure. Even though the Quectel EM060K-GL is globally certified including regional and carrier certifications, some carriers might restrict VoLTE to their certified devices, there is no way of knowing this beforehand without actual testing. As of our right now we have activated our ninjas 🥷 in US, EU, CA for field testing and confirming the results. We are also looking for more ninjas in UK, AUS, NZ, JP - reach out to us at support[at]mechasystems.com, or ping us on Discord / Matrix.

We will be making the 4G LTE Add-on available on September 19th - we are buying some more time to ensure we can give all clarity you need on regional and carrier-level. We have already procured first 500 modems, so opting for LTE will not delay your shipment.

Future-proofing for 5G (RedCap)

Can we eventually support 5G? This has been on my mind all this while. Supporting 5G is not as easy as bringing in a different set of antennas and adding a 5G modem. There are additional tuning features put in place on the Comet’s PCB optimized for the 4G bands.

After some discussions internally and with the antenna design team, we are expanding the support onboard for 3300-4000 MHz frequency range in our existing antenna design. This helps us accommodate support for 5G Standalone RedCap bands. RedCap stands for Reduced Capability; this is a relatively new specification designed for mid-tier devices avoiding the full design complexity of 5G. This means the Comet will be able to support 5G but not at the highest bandwidth it can offer, theoretically 5G RedCap is 223 Mbps / 123 Mbps, that sits between LTE CAT 4 and LTE CAT 6.

So even if you opt for LTE Modem kit today, you will be able to swap it up for a 5G modem later with a new set of antenna brackets. Few reasons why we are not offering 5G Modems right now - (i) Regulatory overhead is real (ii) Expensive pricing of the modems (memory crisis 😭) and (ii) 5G Standalone / RedCap is still expanding across the globe.

This is how the LTE and NR bands map for the Comet’s cellular antenna design.

Revision 9 PCB in-development

One unfortunate side effect of the antenna design makeover is we had to make to make some important changes in the PCB design. Every component and trace in the area highlighted below had to be removed to provide sufficient clearance to the antennas.

This resulted in moving of certain parts and redesign around this area, this means we can no longer use the Revision 8 PCB design (the one shared above) to validate our mechanicals. Instead of waiting on the actual Rev9 PCB to get ready, our PCB and Mechanical design team over the last 2 weeks have iterated and agreed upon the Revision 9 PCB design (they rarely agree 😶‍🌫️), and we are releasing its mock PCB for production by tomorrow.

Instead of a 12-layer high-speed design, the mock PCB will only be 2 layered regular FR4 that we can get it fabricated and assembled in under 6 days locally in India.

This mock PCB will then be used for all mechanical validations, and we can release the injection moulding dies without waiting for the actual PCB.

The actual revision 9 PCBs for I.MX8M Plus, I.MX95 are in design now and scheduled to complete by end of this month. These will be Pre-Production Validated Test (PVT) prototypes, and this time we have their required components procured ahead of time.

Moving to DFA and DFM

Now that our PCB mechanicals are finalized, and our overall design checklist is complete. We are have been focused on design-for-manufacturing . This involves design improvements, verifying tolerances and overall assembly. This ensures all the parts can be manufactured easily and they work well together in assembly.

Here is what our calendar looks like for the rest of this month.

The below list covers all the major parts other than the PCB, as they assemble the overall Comet.

Extensions

The Gamepad PCB arrived last month, and we were able to solder it, assemble it and validate it. Happy to share that the Gamepad PCB is fully functional.

We’ve been testing the Gamepad Extension by playing games with it using the external USB-C 🎉, and we’ve included a video below showing it in action.

Note - the Analog Stick wasn’t directionally calibrated 🥲

This time it was calibrated 😂

Based on this we have also finished our pre-production design and moved into validation for the Gamepad. This is what the internals of the Gamepad looks like, tiny details are captured to such as - ensuring the keys don’t rotate on the its axis, the silicone pads don’t displace, ensuring a clean silicone’s travel and strengthening the overall frame.

Keyboard gets the external Type-C too

A lot of folks asked for this when we brought it in for the Gamepad, happy to share that my annoying self has persuaded our PCB designer to find a place for an external type-C on the keyboard as well. 

QWERTY, QWERTZ and AZERTY layouts

Here is the updated QWERTY layout, the only added change are to the Comma (’) and Period (.) keys on the sides of the spacebar. The Comma (’) and Period (.) are on the first layer, and the Question (?) and Front Slash (/) go on the second layer.

As promised way back, we are also going to offer QWERTZ & AWERTY layouts for the keyboard apart from QWERTY, with the caveat that the physical placement of the keys will remain the same between all the three layouts. Here are our first version layouts -

🔍 Access their high resolution images here - QWERTY, QWERTZ, AZERTY.

Call for Feedback (again)

The QWERTY looks almost set but our feedback channel is open, but we especially need your help on the AZERTY and QWERTZ layout. We aren’t native users, but we have tried to piece together a version that felt logical while looking at multiple layouts and attempting multiple iterations. Please use the link below.

Share feedback here: https://app.youform.com/forms/xjpo6yih

We are hoping to give a full demo on the keyboard in the next update!

Addressing some feedback on Keyboard

We received a lot of comments and inputs from folks on different channels. I have added some more clarifications here -

Why the Pointing Stick? A lot of you liked the trackpad, mostly because it felt familiar. We have stressed this before, but the experience on the Trackpad for vertical movements is a terrible. The resolution of the trackpad to the display size ratio forces you to swipe few times to reach from top to bottom edge. The Pointing Stick feels natural for your thumb and it is a significantly better experience.

No dedicated arrow buttons? On surface this looks like a pretty big miss but as much as we would have loved dedicated arrow buttons - their sacrifice had to be made. We debated heavily internally before the call was taken, but the pros outweigh the cons for this decision. We now have a much better layout overall, dedicated Tab key, duplicated Fn keys, multiple dead keys and dedicated Num key.

No more key swapping? Again we had to compromise on key swapping for the bigger key sizes and overall improvement in mechanism. Now that we are offering QWERTY and AZERTY, I hope this reduces its requirement further. In future if there is a reasonable demand we are okay to do more layouts.

Keyboard and Gamepad PCBs ready for Pre-production

The Gamepad PCB is now fully validated from our end, and we share the same microcontroller on the Keyboard. We are now releasing the pre-production PCB for both the Gamepad and Keyboard. This helps us complete the mechanical validation planned in this month (Sep).

Software

All in on Stability!

Since early August our software teams have been focused on driver-level and BSP (board support package) stability. We are looking at every nook and corner, calibrating every component for its function and performance. This way we reduce any unexpected issues later in the pre-production and production versions of the Comet. I will highlight some of the major stuff we have worked on. To start with we’ve concentrated on Display, WiFi and USB.

Fixing the Colors on the Display

Our design team reported an issue with the colors on the Comet while testing their UI/UX. The colors on the Comet are a lot more saturated compared to standard sRGB display. You can see the issue clearly on the photo below.

On investigation on the display level, we understood the physical light emitted by an OLED panel does not inherently match the color standards of the content we watch. So, if you set Red (#FF0000) you will end us seeing the red emitted by the OLED, which will be way saturated than what a ‘normal’ red should look like. This means that the colors rendered on the display need to be corrected before they are passed on to the Display.

Using the color chromaticity data shared by our panel manufacturer, we were able to correct the colors by creating a Color Transformation Matrix. The i.MX8M Plus does not have a hardware color correction capability while the i.MX95 does. So we went ahead and implemented it on our Wayland Compositor, making the colors on the Comet start to look normal.

Fixing Random USB Malfunctions

We hit a strange bug, USB 3.0 would randomly stop working on the 2 USB-C on the left of the Comet. This was hard to decipher, and we spent good time - trying to recreate this issue across multiple boards for the last revision.

A typical System-on-Chip, would have a fixed number of physical pins but they can be shared by multiple peripheral signals. In this case the physical pins we mapped for USB 3.0 were mapped to Ethernet on u-boot (probably for netboot) and we re-mapped them to USB 3.0 on the Linux kernel. This created random power cycle issues causing the USB 3.0 to malfunction. All credits to Bhushan Shah (long-time KDE maintainer of Plasma Mobile and friend) in nailing this down for us.

configs: disable ethernet subsystem · mecha-org/u-boot@e4c9a62

We do not have the ethernet on comet, and unlikely we will have it. But enabling this seems to cause usb3.0 to fail later in boot cycle. So just disable this. Signed-off-by: Bhushan Shah <bhush…

GitHubmecha-org

Power Optimizations

As programmers, we all love optimizations. This is something we have been looking at closely over the last few weeks and have some solid updates to share.

Enabling WiFi Power States

We spent some time validating the WiFi Power states to ensure actively connected WiFi does not take a toll on the battery life. Using the upcoming nxpwifi on mainline, we have tested the standard IEEE PS.

WiFi with Power Save OFF: Uses extra 0.3W while connected to an AP, this is because the WiFi antenna keeps running in receive mode waiting for packets to arrive

WiFi with Power Save ON: This saves the 0.3W on the battery, putting the antenna to sleep and wake-up in fixed intervals to check if there is any packet held by the router.

While doing this, we’ve also got WoWLAN working, you can wake up the Comet from suspend with a unicast packet (like a ping). We will be pushing a fix on upstream for this.

Our next step will be to enable Target Wake Time (TWT) for even better control on wake-up.

Adding Device Frequency for DDR

This is something I personally learnt as part of this optimization work. Usually when you are optimizing for power the focus is on the SoC cores, and we don’t really pay attention to the DDR (we never did). Now modern DDRs like the Comet’s LPDDR4 or LPDDR5X run at 4266 MT/s or 2133 MHz at its max speeds, but it can also run at lower speeds - hence saving significant power. The Linux kernel’s devfreq subsystem can manage this using governors.

The I.MX8M Plus standard EVK does not enable this by default but the support exists. But adding this block in the device tree can hook up the imx8m-ddrc driver that supports the imx8mp.

Here are some results -

By scaling the memory down to 25 MT/s in its lowest state during idle with display turned off, we were able to reduce idle power consumption down from 1.5W to 0.8W, that is a saving of 0.7W of usage 🤯. But there is a big nasty but -

When the display is turned on, how do you scale the frequency down to 25 MT/s when you are supposed to send framebuffer of 1080x1240 pixels, 60 times in a second which is 240 MB/s of data transfer from RAM → Display? Luckily, we have an answer for that.

Enabling Self-Refresh / Command Mode on the Display

Remember in the last update, we spoke of our work into Command Mode for the Display - just a quick recap. Our display has its own GRAM, which means unlike traditional displays - which need continuous scanout from the Display Controller → Display, our display can refresh from its own GRAM without the Display Controller sending new frames on idle. By leveraging this, we can solve the problem shared above. We can continue to keep the display on while the scanout is disabled, so the DDR is not being hammered 60 times a second.

This not only helps during long idle but even in active usage you would have short durations of idle. Let's say while reading something or navigating between apps. For a computer even 1 second is a very long time. This graph will help better understand.

We are able to get this working end-to-end and are seeing the power gains as expected 🎉 . The only issue we have now is a frame synchronization, when the UI on the display needs to be updated, the Display Controller again starts sending frames to the display, overwriting the previous idle frame visible on the display. The timing for this new frame needs to be accurate, we have to send the new frame before the vblank of the next frame. Vblank is the small pause the display takes between rendering two frames.

To better show the problem, we have a clock on the status bar that is updating every second. You can see the tearing effect every time the Display Controller wakes up (devfreq on DDR is not enabled)

We will continue working towards this, hopefully we will have resolved this next month. We are so close 🤏.

Overall Power States

I have compiled different power states we have achieved so far. In all these cases, the WiFi is connected to an Access Point, Display is at full brightness. To measure accurately we have a power source connected directly to the battery terminals.

Here is a quick demo of waking up from suspend state, this is the state we can enter when you lock the device and leave it for 5-10 seconds.

The above numbers can still improve but this is already looking good! Here is a quick video of the Comet going to suspend and waking up.

Launcher & compositor updates

We have been talking on and off about our crusade in building our own UI and Wayland stack over the past couple of months. We are now at a stage that we can now actively start building the shell and other UI elements on top of these core components.

Here is a demo of an initial lockscreen built using our UI engine and running on our Wayland compositor. Our compositor like the niri and cosmic compositor builds on top of Smithay, it is an amazing library that helps abstract a lot of internal Wayland details so that we can concentrate on the display manage features. Our reasoning for building our compositor is to be able to optimize its performance for the Comet, have flexibility of custom protocols and manage upstream protocol changes better.

This is still not our fully optimized version, but hey it works well. The app drawer for now is wofi

The development work for this is being tracked on multiple repos on our Github Org. You can find our Wayland compositor repository here -mechanix-comp

Tinker Design System for Mechanix OS​

Our Tinker design system is now in place, and we have actively started building its primitives for our Rust-based UI engine for the shell and for Flutter. Here are some glimpses of the new design system - 

Supply Chain

We have iterated this before but this is probably the worst time to build electronics, let alone launch a new device. As of right now semiconductor manufacturers are delaying deliveries and a number of them have revised prices of components multiple times. Some of them have cancelled orders even after 6 months of ordering in advance. Price increases are something we have absorbed, but for some critical parts that cannot be replaced, we have no choice but to wait for their deliveries. We have an on-going effort coordinating the supply of all components necessary for the Comet.

We want to be as transparent as possible and set right expectations. As of right now, our last semiconductor components are scheduled to arrive between 31st October - 7th November. We cannot start mass manufacturing the PCB till these components have arrived. Here is a high-level tracker of all critical components and their current status -

Our in-house stock has also reasonably grown. More shipments are incoming this month (Sept) and next.

Upcoming Milestones & Delivery Schedule

I have mapped out our upcoming milestones - covering validation to delivery. I am sure it is pretty obvious now, that we cannot ship by the late October timeline, and shipping late in December is tricky.

Based on current timelines, the Comet's deliveries will start from January 2027. 

We remain committed to deliver the best version of Comet that we could possibly build, no compromises there. Thank you for your support and patience you have offered us in making the Comet a reality. Delivering the Comet remains our only right now goal, though I am really looking forward to how the ecosystem evolves around it next year.

Our website will reflect the updated timeline in the next 1-2 days.

----------------------------------------------------------------------

Thank you for reading through the end! August has been a busy month for us, but we are picking up the pace further in September to knock off the on-going items and the ones coming up.

Thank you everyone, see you in the next one!

Shoaib & Mecha Team