SAD CHILD <--- Help Battery issue


IMO, with regards to DIY or availing a service to fix them depends on a few factors:

  • convenience
  • budget
    • can you afford it?
    • how many Mekas?
    • short-term and long-term
  • knowledge/skill
  • the main purpose of buying these robots

These factors vary for individuals, so I can only speak for mine.
For convenience, I would go for ckalkhof’s eBay battery replacement service, no question about it.
Consider also if its just a “fad” for you and/or the kids.

If it is, then its only for short-term, please read no further and go with the fix/replacement service.

It will save you time and frustration.

In terms of budget, personally I already over-spent last December. It’s not only for the 6 Mekas but other things in general.
When I bought them, they were priced at $50 (with shipping) and $35 (free shipping).
Now they are going as low as $28 (free shipping). Even with defective batteries, that’s a catch.
I’m pretty tempted still.
So on the practical side, they will cost substantially more for me to get the battery fixed.
On an added note, I also considered the long-term. As I mentioned earlier, li-ion based batteries (li-pos included) will eventually expire (self-discharge, charge cycles) and lose their capacity over time. This is inevitable.
If you happen to be still interested (not a “fad”) on Mekas when the batteries fail, whatever route you take (DIY/fix), you will have to do it again.
I have already considered that in my battery-mod.
Hence I opted to include a battery holder to make it easy for me to swap the batteries.
18650’s are a commodity that makes them cheap and widely available as opposed to the original li-pos used here.
I’m considering 3d printing a custom case in the future to improve the over-all design.
But that’s way down in my to-do list if I somehow get to it.

For knowledge/skill, I’m not an expert, but I’m fairly capable.
I also understand the dangers involved and I take precautions.
This is just another adventure for me. :smiley:
Understanding everyone is different, it’s not for everybody.

Now for my main purpose of buying these robots, having to play with them is just a cool bonus, I look at them as parts that fit a bigger system/vision.
That’s why I purchased a lot.
The money I saved, makes up for the parts that I need to purchase later.

Anyway, that is just me. :smiley:

Btw, there is a 3rd option, but I would admonish anybody else to do it.
I have 5/5 of the original batteries revived without opening them.
These were the new but DOA Mekas. IMO, their battery succumbed to self-discharged.
There is a 6th that I didn’t count because this is the I one opened when I studied my battery-mod options.
1/5 likely has a defective BMS since I cannot charge from the OEM charger directly.
But 4/5 so far, I have not any other problems.
Though I know, they will likely have reduced Capacity.
It’s just their nature.

About the battery indicator, I would second or third that the red lights on the rear of the V1 are not an indicator of battery charge. That got me too at first.
I would also check the Mekamon app or the Reach Edu app for it.
On a related note, 5/5 revived batteries are showing full capacity on the app.
This is compared to my battery-mod, where they are only showing about 70-80%.
Note, those are used 18650s too.

The BLE protocol actually advertises the battery charge in terms of millivolts and milliamps.
The battery indicator is computed in percentage based on these values and the difference to the minimum battery level.
The app indicator is not that accurate too though as per other threads in this forum and my experience as well.

New to Mekamon - Amazon Special

Knelf, you read my mind. When I confirmed that the app is missing in the Android Play Store, I was thinking what would be next? the app in the Apple App Store? this forum?

I think it’s another Elephant in the room that we need to address.
I’m all in for your suggestion to have an alternate site and/or sort of semi-archive of this forum.

Btw, about the SSL certificate, unless they renew, this forum’s SSL cert will expire on 3/12/2020. As of now, we have about 38 days until the browser starts to complain it’s validity and depending on your browser may refuse to load any of the site’s content.

For the APKs, thanks for raising the alarm to keep backups. I have mine as well.

Apkpure keeps versions of the old apps (and their own XAPK).

I did some checking for version MekaMon_v2.3.0:

MekaMon v2.3.0 Official OBB (extracted from my Android)
Size: 141100647 bytes (134 MB)
SHA1: 6E30ADF259CA08BA530F005B18098D7E474AB9FF

Size: 141100647 bytes (134 MB)
SHA1: 6E30ADF259CA08BA530F005B18098D7E474AB9FF

XAPK apparently is just a ZIP archive.
I just used 7-zip to extract the contents.

The hash do match for the original OBB file.

The APK file per se, I will be checking later.
It’s possible to modify APKs file to add malicious code so I’m reluctant to use them as-is until I have analyzed them.


oh well done rave on thinking about the forum cert expirey. TBH I was thinking the digital preservation clock was ticking from the moment I realised the company had died but I will admit to dragging my feat a bit.

On those APKs I’m a little confused. For my own (extracted from my phone) backups I have:

Reach Edu_com.reachrobotics.reachedu.apk Version: 1.1.0 Date: 02/02/2020 Size: 60.5MB SHA1 Hash: dc9243bff4f74c1b8a4168b66adef2cf81efaf4d
MekaMon_com.reachrobotics.mekamon.apk Version: 2.3.0 Date: 02/02/2020 Size: 31.5MB SHA1 Hash: 59958ddad8015c2ea7f2e6313b3fcffdbf610e11

SHA1 Hash calculated using this tool:

edit, on the extraction thing and the potential for malware… I was working on the principle that if the app I used was on the play store… then hopefully google will have checked it isn’t up to any funny business…

Maybe I’m being too optimistic there though!


The one I posted are the related OBB files, not APK. OBBs are application-specific DATA files.
Normally OBB gets re-downloaded when the app detects its missing, however, given that the Mekamon APK installer is already missing in the Play Store, we can’t guarantee that it will still be available for download.
They could remove it as well.

I’m still working on obtaining the original APK files. Android made changes over the years such that the original APK is no longer easily extractable. I have to use an APK Extractor app but I don’t trust that yet.

Can you obtain the SHA1 hashes of your APK files for comparison?

Btw, with regards to my malware comment, yes Google does remove malicious apps, but its always a cat and mouse game. Same case with iOS. No OS is perfect.
Some malicious apps are evasive (a Dr. Jekyl and Mr. Hyde case) such that it takes months for them to be classified as one and eventually be removed. Hopefully, that’s not the case for the Mekamon app.
So far, it’s not being flagged yet so hopefully, that stays.

Btw, I have downloaded all the community/public Mekamotions via the app before. Those are just json files containing base64 encoded blobs of the saved custom motions (joint state control mode).
I will be backing them up just in case.


Thank you very much Miraenda. I’m very glad the batteries worked out for you!


I’ll find out how to do a SHA hash on those files and let you know. EDIT: Added hash to above post

Good work on backing up the community submitted mekamotions (joint state control mode - I see someone else has been busy reading the manual :D). With regard to backup I wonder about restore too? i.e. if “where they came from” goes, how would one go about installing your backed up JSON files? I’ve not actually fetched them all into the app yet… I should do that ASAP really.

About the DATA (OBB) files, so what I’m understanding here is that there is some extra data that gets downloaded after .apk install? In which case yeh, we need that backed up too, and a way to restore.

Fair points on cat and mouse. Ideally they’d detect a nasty apk extractor before they put it on the play store but I guess maybe investigations are retrospective after reports of foul play.


It’s actually not in the manual. :smile:

Good news!
Buried in the OBB are the firmware and the custom animations/mekamotions.
They are no longer retrieved online as I originally thought.
They are extracted from the OBB by the app.
Good thinking of RR. They thought of the customers and remove the web dependencies. This justifies backing up the APK and OBB.


Page 2 of the educational one 1st line. :wink:

With the custom OBB containing the animations… does that mean we can no longer create and share animations via the app? So if I went home and made one now, I can’t share it with you? (sorry have to admit I’ve not checked the functionality around making/sharing animations yet - sorta waiting till I have an “on board” battery before having a proper play).

With the APK extraction, was thinking if you use a different extractor to me, and we compare the SHA1 hashes and they are the same. Would it be fair to conclude they are “nasty free”? OK I admit there is a chance that both extractor apps use the same nasty code but I think we are getting into unlikeliness at that stage?


About the firmware in the current app (standard and educational) is it possible to determine what version the firmware is? I’m sort of hoping it is “the same” as the custom firmware embedded in the special apk that turns on the debug mode/USB port. This would be handy.

What I’m thinking is… if, down the line, I try out the USB control, it would be nice if this doesn’t then cause the standard app or the educational app, to keep telling me I have the wrong firmware and wanting to re-flash. This would mean I could experiment with USB stuff but also use the usual games and things in the normal apps (of couse, it could be the special apk has those games too - not tried it yet).

Would be ideal, but I’m not thinking this is likely. I have a feeling the most recent app releases likely have a more up to date version of the firmware than the special apk anyhow.

That said, it might be, the more recent versions of the apps/firmware enable the USB anyhow. The impression I get is that everything was a bit “work in progress” when the special apk was released. To my mind it would have made sense to consolidate everything to work with a single firmware.


I was going to send that info out today with a warning.

The special FW has a version of 2.99 while the standard firmware is 2.18.

The app does check which FW version the connected Meka has. It will only offer upgrade when the version is lower. This means that you cannot revert back to standard once you upgrade. Also, there is some compatibility issue when you use the special FW with the standard app. The Meka would always seem to initialize its leg when idle - a stomping motion.
When the FW and app are matched, it’s back to its normal behavior.
I was looking before on how to cheat the app to downgrade but I stopped since I seem to be the only one with this use-case. Also, I have 6 Mekas so I really intend to have 1 or 2 on the special FW/app.


I have no programming experience, but maybe something in this older post might be helpful-- the post was about refreshing old Beta units so they’d be compatible with a firmware update, but maybe some of the info provided might apply to what you’re doing…


On the special FW and app, they do have the games still.

The one difference I noticed is that there is a setting that allows you to change the head color on the standard while on the special, its replaced with the type of floor(carpet, tile, etc.). These makes some adjustments on the height, speed, etc.

It’s possible too that they enabled usb debug mode on the latest standard FW. I wished they did but I have yet to confirm that.


Cool! This is useful to study.


Ooops, looks like I have downloaded the tool before last December. I completely forgotten about this. Thanks Benerator!!!


Thanks @Benerator that was a really interesting read about the manual way to update the firmware. Useful info there about the tool and the process to update. Also intriguing that the firmware was so small. Given I remember it took about 15 mins to do my original firmware update, this did surprise me.

Some thoughts I had while reading that. We should bear in mind the firmware provided in the thread is for nerfed beta bots. So we should probably avoid using that particular file for production bots (not that anyone would never hurts to put it in writing). I also wonder if the firmware is for the Bluetooth module, or for the robot “brain” so to speak? Call me paranoid, but thought I should at least ask that question.

edit: inside the download file are 2 files with nrf51422 in their titles. This makes me think the issue with the beta bots wasn’t that “the brain” needed updating but the BLE module needed updating. If you search for nrf51422 you’ll see what I mean. e.g.

So probs this next para is wrong:
Anyhow, assuming it is for “the brain” so to speak, I’d suspect that the method could be utilised to “downgrade” firmware in Rave’s case where he has put the USB/debug firmware on one of his meks. We’ll have to see if he fancies trying it.

Rave thanks for the info on the USB firmware. That’s really interesting to know that it is actually a later version than the one packaged with the standard apps. Interesting too about the app changes. I guess they were working on adjustments to deal better with carpets and so forth. I’d bet this was in an attempt to combat the clicking some. I’ve noticed more click on carpet than lino. I don’t think this is a fault (more a design intention). I’d hazard that the clicking is a clutch of some sort disengaging slightly. So yeh, adjusting for stuff like how much “up” happens before lateral movement would probably help. Just a guess though.

A thought on the USB functionality. It might be there is “some” functionality on the USB port out of the box, it just might not be the “right” USB functionality for the educational module (meaning maybe they changed it). During manufacturing testing, they used the USB port to check stuff was working. I’d hazard that it wouldn’t have been sensible to do the testing THEN re-flash the firmware (as in theory there is then something new to test) but they might have done if they thought the chance of introducing issues after a re-flash was minimal… to be fair, it probably was.


Regarding the USB port, when I first received one of my Beta units, I was having issues using the AR functionality, and they had run a diagnostic test (which at the time revealed that the problem was a defective IMU). At any rate, maybe these troubleshooting steps will help someone (keep in mind this was for a Beta unit, don’t know if anything changed with the implementation for the V1 or V2):

Do you have access to a PC?

Can you install TeraTerm ( or do you have access to a serial coms terminal?

If have answered yes to the top two can you remove the USB cover on the back of the robot near the back button and plug the robot (leg attached or not) into the computer.

You will need to find the COM port the robot is attached to (will change depending on USB location and computer)

The default COM settings are

Baud Rate = 9600
Data = 8bit
Parity = none
Stop = 1bit
Flow control = none

The Mekamon should begin streaming basic debug information to your screen now.


DIS Motor: 5.7V, Battery: 11.6V, Power: G Peak: 439mA Motor: -117mA Seq: 2
DIS Motor: 5.8V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 3
DIS Motor: 5.7V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 4
DIS Motor: 5.8V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 5

Give the robot a few cycles and type “di” into the terminal. The robot should now give you IMU debug information. Let the robot sit still for a few seconds then move it around.

Please take a log of the terminal out (or copy and paste) back here to me.

If the unit reads back all 0s or all 1s on the IMU debug then it is highly likely your robot is defective.


Thanks Benerator!

I tested the USB debug mode on Mekas with firmware (FW) versions 2.18(latest), 2.99(special/edu) and 1.10(out of the box).

Both 2.18 and 2.99 when connected to a PC are recognized as USB HID devices but not as USB Serial COM port. Fortunately, I have one Meka that I haven’t updated and was still on 1.10. This had USB Serial enabled. Probably this FW was part of the Beta.
Once connected, it echoes debug messages similar to Benerator’s example.
I tried the ‘di’ command and it did show IMU infos.

I cannot find any documentation on the supported commands so I brute-forced by iterating every character from A to Z, numbers and symbols. It’s case-insensitive fortunately. When the first character is recognized, it outputs the available commands that begins with that character. I captured the output for later documentation. I will share them on my next post. It’s very interesting. Commands can query and set values, some can do playbacks of system animations, set modes - linear, gyrate, mimic, sit, stand, etc.
I haven’t found how to set the head color yet or set the leg, thighs, etc. More research is necessary.
I hope I can find out from the firmware.

Btw, with regards to the possibility of downgrading the FW from 2.99 (special/edu) to the official 2.18, short answer is YES.

I also have concerns about the DFU process. The more I researched and from comparing the firmware in the OBB and DFU firmware from the old thread, I believe the DFU firmware may have only been used to update the BLE bootloader. It might be too risky to even attempt to use the same process and DFU FW as it could brick the Meka. I think it’s possible though to use the same process but we need to have the correct DFU package in order to do so. The FW in the OBB is in a different format. It was stored in a JSON blob as a b64 string. Decoding the b64 to hopefully get the binary and it appears to be encrypted still.

Anyhow, I tried another method. I mentioned that I was thinking to cheat the app so that it will force the FW update.

My first attempt was to see if I can cheat the app into seeing that the OBB firmware version is higher.
I patched the OBB file and changed the FW minor version from .18 to .19.
I uploaded the patched OBB and started the Mekamon app (restored from backup). Btw, I can confirm that installing the APK is not enough. The app just hangs without the OBB. I copied the OBB from backup and the app loads fine again.

Going back… to my surprise, once I connected the Meka, it prompted to update the FW to 2.19.

Other than patching the minor version, basically a 1 byte change, I’m thinking it should be safe since basically I’m pushing the same FW (2.18).
After 18 mins of wait, it took a little bit longer but once it rebooted and reconnected to the app, the updated FW version still showed 2.18. This was expected since I never changed anything else and it should apply the internal FW version. It prompted me to upgrade to 2.19 again.
I then reverted the OBB to see if the Meka is still working like before. I didn’t see any issue. This was a good sign.

So the moment of truth was to see if I can donwgrade a Meka on 2.99 back to 2.18. I made a new OBB by patching this time the major version from 2 to 3. So the app would see that it had the higher 3.18 FW and force it.

It did and I proceeded with the ‘fake’ upgrade – but really its was downgrade. This time it took like 30 mins to finish. So I was a bit worried that it failed. However once the Meka rebooted and reconnected, it showed 2.18 FW - a success!!!
I reverted to the original OBB (2.18), it no longer prompted to upgrade since the versions are the same.
I did the basic tests and didn’t find any issue. Also the compatibility issue I mentioned when using a Meka with 2.99 FW with the latest app, where it continuously stumped its legs when connected, is no longer there; proving further the successful downgrade. It is now fully compatible. :smiley:

New to Mekamon - Amazon Special

Btw, about the special firmware, I think they made it so it only works on their custom RPi, Ubuntu with ROS or with a special driver.
That requires some setup so I’m postponing that for another day.


I mentioned the upgraded versions (2.19 and the special 2.99) shows up as USB HID and not as Serial COM ports.
On the 2.99 FW, the documentation did mention about using a USB HID library.
Thus to use it, ROS interfaces with the Mekamon Base Controller module that translates the ROS commands to Meka commands.


Rave you are doing an absolute legend there in experimentation! (and thanks too to Benerator for sharing the info about the legacy USB control).

Glad we are of the same thinking on the Bluetooth radio’s firmware update.

My guesses are that the older text/command based USB protocol got ditched for something a bit more swish. It makes sense. You start with text (everyone starts with text) and then when you have your own software or library to control things with binary, you switch to that.

Probably something can be figured out about the USB HID driver from the raspi pi image down the line when one of us gets to that (I’ve not even read any more of the manual since last week). I did note though it said something about a bit of the ROS interface being supplied as a binary only though, so knowledge of exactly how the USB protocol works might be won harder than one might like. Still, a job for another day.

Really fantastic news to know that we can flip Firmwares at will though. A superb step forward. I guess I’ll need to find out how to extract this OBB you talk of rave. I’ll add that one to the learning list.

Just a note that I’m holding fire (for the most part) on my mekamon experimentations for now while I concentrate on building my own robot for a bit. That said, I am planning on having a go at resuscitating the stock battery and am, gradually, reading the educational manual… and of course all the fantastic updates on this forum!

Incidentally, quick question about the 2.99 firmware and the “stomp”. Would you say it looks like something has “gone wrong”? or is it simply a (perhaps poor) choice of “idle” movement from RR for that release? i.e. is it the modern equivalent of the standard “looking around then going to sleep” action it does these days.

I have to say, at first, I was disappointed that, after the standard firmware update, the meka lost its “when idle” penchant for random violent emotes (which were fun if a little scary!). After a while though, I got used to the more calmer “when idle” emotes, and in some ways I was kinda glad it wasn’t jerking around in an unpredictable way any more (especially with my somewhat delicate “tether” solution for power).