![]() |
Originally Posted by Chof
(Post 16078394)
Simply download the SD card contents from the RadioMaster website and overwrite your SD card.
If you back up the current state of your SD card, you can return to it at any time. The ELRS module will need a reflash if you have configured custom wifi settings, otherwise you can generally reset settings from the wifi configuration page. It's worth noting that on EdgeTX and similar OS's, the OS software and the RF module software are separate and certain RF modules (like ELRS ones) have some settings stored in the module instead of stored in the model file and sent to the module on model selection. |
Originally Posted by mawz
(Post 16078724)
Just deleting the radio.yml file and any modelxx.yml files off the SD will do a reset on the core radio.
Zoomies wants a way to do a factory reset, so he needs to copy the RadioMaster's SD card contents. |
A few thoughts on this radio.
I'm relatively new to the Surface world, but I am a very experienced airplane radio guy. I'm mostly an FrSky guy over there these days (ETHOS OS and TANDEM/TWIN RF) but I have a lot of experience with OpenTX and EdgeTX, and am reasonably familiar with ELRS (I run some ELRS stuff just to keep up on it). Since FrSky doesn't play in the pistol-grip side of the Surface market, I picked up an MT12 to replace my cheap FlySky radio as I build more vehicles. The MT12 is a mid-range radio from RM's perspective, based on features and model name. It's pretty clearly the surface equivalent of the Boxer (which sits alongside the Zorro and TX12mII as their mid-range air radios). That means if it's successful there will likely be an MT16 (higher-end colour radio) and a lower-end MT8 or MT Pocket. EdgeTX is going to attract a lot of Air guys to this radio. They will know how to program it and be comfortable with the ecosystem. Note that for things like naming conventions (Rates vs Weights, EPA vs Outputs Min/Max, etc), these are growing pains that happened in the Air market, so don't expect Surface naming conventions to be adopted, with a decade or more of documentation out there for OpenTX/EdgeTX, the core UI is not likely to change that much aside from really obvious items (Drive Modes vs Flight Modes for example). Custom UI Lua is a very standard approach in OTX/ETX and I expect a bunch of them to pop up over the next little while as everybody comes up with their preferred screen layout. In the air market, the top 3 systems today really are Spektrum, FrSky (now on ETHOS, but also some OpenTX stuff still) and the non-FrSky EdgeTX/OpenTX radios. In the quad market it's Non-FrSky EdgeTX/OpenTX radios with FrSky stuff in second and nobody else. Futaba is still a player with folks who have been around for a while, but you rarely see new pilots go Futaba. Jeti and Powerbox play at the real high end, but sell in low quantities for much cash. I see some very big benefits to the MT12 in the surface market. 1. Bridging the gap from AFHDS 2A and SLT to high-performance RF. A lot of folks have cheap AFHDS 2A radios (including me), and before the MT12 you pretty much had to buy all new receivers if you wanted to move to a higher-end radio, even in the FlySky ecosystem. The 4-in-1 supports AFHDS 2A today and the internal RF + Module combo the MT12 offers lets you run 4-in-1 + ELRS on the same radio. The same combo works for SLT, and several other surface protocols (although a fair bit of the Surface protocols aren't supported on the 4-in-1, and some like ANT never will be for hardware reasons. FYI - The FRM303 AFHDS3 module should work fine on an MT12 and support high-end FlySky receivers, for FlySky users it's just ANT that's out in the cold with no 4-in-1 support and no module option). 2. More flexible mixing & curves. It will take a while, but I suspect folks will find there are tuning options available for the more adventurous programmers that can ease driver workload. That will have to develop over time as people develop solutions to problems you probably didn't even know existed. One of the biggest things is that virtually everything can be live adjusted, and adjusters can be overloaded (so a trimmer can adjust multiple things depending on other switch positions). One thing I can see already is that you can have both throttle-based steering limiter (rates proportional to the current throttle position, or even to speed via telemetry) and steering based throttle limiter (dropping the throttle rate based on the current steering position), with this being live adjusted so you can dial it in on the track as you do test runs. With EdgeTX a big thing is doing complex programming before hand to simplify tuning and operation when you are flying/driving. Another thing is templating so you never have to do it twice, program once then duplicate/share the template. 3. Open Source development. The killer item here is that missing features like ABS can make it into test builds very quickly, and the dev teams are very open to adding features if those features are well described. You can also extend and customize the system via Lua scripts so you can extend the system without relying on the core OS team to deliver functionality. This is probably most useful for optimized UI variants and configuration scripts (for ESC or Gyro configuration from the radio, both things we've seen in the Air world). This also applies to the RF systems. I've already seen a bunch of requests for additional surface protocols to be added to the 4-in-1 firmware now that there is a proper surface radio with a 4-in-1 module. You also are no longer dependent on a manufacturer's current interest in the product line to get support, witH ELRS in particular it's an open protocol so anybody can make receivers and RF modules for it. 4. MUCH better support for FPV systems than you have seen before. Thanks to the FPV quad market being the core market for both the OS and RF system, VTX and headtracker support is already excellent in both the radio and the receiver system. This is a small market for Surface today, but I expect it will grow faster than you expect, especially since Beyond Visual Line of Sight (BVLOS) on the surface is legal in many places where BVLOS flight isn't. 5. Hardware modding/custom hardware. We're already seeing this start to appear (An OLED screen mod is already in the wild, as is a clip-on switch/pot expansion unit which adds extra switches and pots to the radio for the complex scale stuff). There is a huge level of support for hardware mods at the transmitter level in the EdgeTX community and I expect the MT12 to be no different. If you don't like something about the hardware design, change it (or go looking for a mod by somebody with the same complaint). Wheel drops, lefty conversions, etc. Frankly, I don't expect the MT12 itself to be too massively disruptive initially, it will take time to build up some momentum. In the air market, it took 3-4 years from the introduction of the FrSky X9D (the first commercial OpenTX radio) in 2013 to true market disruption where it started to replace Futaba as the #2 brand for new buyers. But with the MT12's arrival, the barrier to entry for the surface market just went down a lot, and I expect if it continues to sell that we will see more surface radios from RM, and possibly even other manufacturer's in the EdgeTX & ELRS communities to get involved (I'd expect we will see at least one surface-oriented product from BetaFPV and Jumper by the end of 2024) I personally think ELRS is a really good fit with surface rf needs, where I've been somewhat skeptical of it for fixed-wing air use (ELRS has ecosystem limitations right now vs the TANDEM & TWIN systems I fly, around advanced in-aircraft electronics that do not do CRSF but do support SBus/S.Port and/or FBus). In general the telemetry needs and integrations for surface applications are already well supported in ELRS (voltage, current and other ESC telemetry, GPS telemetry, ESC and Gyro tuning), it just needs ESC's and Gyro's with ELRS integrations to become more available and that will happen if the MT12 takes off (and I think it will). |
Originally Posted by mawz
(Post 16078740)
A few thoughts on this radio.
|
Originally Posted by mawz
(Post 16078740)
Note that for things like naming conventions (Rates vs Weights, EPA vs Outputs Min/Max, etc), these are growing pains that happened in the Air market, so don't expect Surface naming conventions to be adopted, with a decade or more of documentation out there for OpenTX/EdgeTX, the core UI is not likely to change that much aside from really obvious items (Drive Modes vs Flight Modes for example).
I also don't like the weird arrow on the main screen that shows the throttle and the weird bar that shows the steering. Isn't it fine to just leave the stick position displayed? In traditional stick-type surface radios, the left stick is the throttle and the right stick is the steering (rudder). This is almost the same as Mode4, RTEA. I'm very happy that EdgeTX radio for Surface has been released, but I'm worried that it will become too customized for Surface and will fall out of the mainstream of EdgeTX and decline in the future. Just because it's a surface radio, I don't want it to be unnecessarily customized, and I would like it to stay in the mainstream of EdgeTX. |
Originally Posted by Chof
(Post 16078769)
I didn't even want the name "Drive Mode" to be used. Isn't it fine to leave it in "Flight Mode"?
I also don't like the weird arrow on the main screen that shows the throttle and the weird bar that shows the steering. Isn't it fine to just leave the stick position displayed? In traditional stick-type surface radios, the left stick is the throttle and the right stick is the steering (rudder). This is almost the same as Mode4, RTEA. I'm very happy that EdgeTX radio for Surface has been released, but I'm worried that it will become too customized for Surface and will fall out of the mainstream of EdgeTX and decline in the future. Just because it's a surface radio, I don't want it to be unnecessarily customized, and I would like it to stay in the mainstream of EdgeTX. I do see Surface-specific Lua becoming standard for UI, similar to how Yaapu has become a near-standard interface for certain sides of the quad market. |
Every single thing you say makes sense, and I'm just impressed.
I'm not familiar with Lua UI, so where should I start learning? |
Originally Posted by Chof
(Post 16078777)
Every single thing you say makes sense, and I'm just impressed.
I'm not familiar with Lua UI, so where should I start learning? Be aware the B&W Radios (like the MT12) and the Colour radios have somewhat different requirements for UI scripts since they're always full screen on B&W and always widgets on Colour screens (which may or may not be full screen) |
6 Attachment(s)
I'm almost ready to share my LUA script for what I want to see when I'm at the track (for the record I'm using ELRS). I need to get all of my troubleshooting removed and comments cleaned up. Attached are some screen shots. One is with no receiver connected, one is with the correct receiver connected, and the last is with the wrong receiver connected. (This is the Model Match feature.)
I did exactly what MAWZ suggested. I use the 3 position Switch A to toggle the trim switches around the wheel. So switch A selects between "none," steering, and throttle. Then T1 is weight/rate, T2 is trim, and T3 is expo. To split forward/brake, I split the input and put the brake weight/rate on T5. Give me a couple days, and I'll post my template model and the Lua. |
Originally Posted by mawz
(Post 16078787)
I'd start here with the lua-scripts repo on the EdgeTX Github (I can't link yet, not enough posts)
Be aware the B&W Radios (like the MT12) and the Colour radios have somewhat different requirements for UI scripts since they're always full screen on B&W and always widgets on Colour screens (which may or may not be full screen) Here's the link: https://github.com/EdgeTX/lua-scripts |
1 Attachment(s)
Here are the model template and LUA script I built. Keep in mind I'm using ELRS, and this probably needs to be tweaked for the 4-in-1.
I'm not allowed to upload yml or lua files, so I zipped them together. Copy the .yml file to the BACKUP folder in the SDCard, and the .lau file to SCRIPTS->TELEMETRY. Once you have the files on on the SDCard, you need to restore the model. Click the MDL button. Scroll to an empty slot and long click the scroll wheel. Select "Restore Model" Select my.yml file name. This will create the new model. Long press the wheel and "select Model" If your using ELRS, turn on Model Match click Page > Scroll down to "Receiver" and set it to the value you set on the receiver ----Make sure you have model match enabled in the ExpressLRS Lua---- Oscar Liang does a good job explaining model match setup here: https://oscarliang.com/the-power-of-...how-to-set-up/ To use/see my display, click the "Tele" button. SA is used in conjunction with T1, T2, and T3. It also has a switch warning at boot. (Push in to clear the warning.) SA in - none SA middle - Steering SA out - Throttle SB - reset timer 1 SC - start/stop timer 1 T1 (ST) - Rate/weight for Steering or Throttle T2 (TH) - Trim for Steering or Throttle T3 - expo for Steering or Throttle T5 - weight for Brake |
Originally Posted by DirkW
(Post 16059557)
Simple fact is: no programming in the world will make a battery suddenly supply more voltage to the ESC than it can physically provide. It's physics, not magic and there are hard limits.
It wouldn't be legal in blinky racing, up in open classes could it be legal? Most every competitive esc has a method to program several things like base timing, boost, abs braking, etc. usually through a separate programming card with a cable, or the power button cable with the programming button on the side or a phone app or something. The question is, could that signal modify the esc timing on demand? Can EdgeTX duplicate that signal? If it can duplicate the signal then a separate channel that plugs into the programming spot could be used for a timing advance. Generally the timing is set for the duration of the race, right? Base timing & boost, or whatever profile the esc has for getting 'optimum' performance is set to the maximum that survives the whole race. It may not be the highest performance because that would overheat the motor. So a driver willing to risk a bit might enable the higher performance setting with the heat risk for a 'push to pass' moment. On a side note, if EdgeTX and the MT12 could duplicate the ESC programming cards, either through a new channel or even the aux port on the radio, That could help a lot of people with older ESCs that the programming card has been lost to keep the ESC alive and usefull. A transmitter that can (in the 4 in 1 version) bind to 70+ recievers, AND replace any ESC programming card you have would be a thing of beauty. |
Originally Posted by amp3d
(Post 16078142)
May I ask how this performs in direct sunlight vs the original screen?
https://cimg4.ibsrv.net/gimg/www.rct...66254dba0f.jpg In any case, visibility of OLED under direct sunlight is not good. It's about the same as a smartphone. Once you are in the shadows, the screen is visible. https://cimg8.ibsrv.net/gimg/www.rct...a0433cac8c.jpg |
Originally Posted by SlideWRX
(Post 16079869)
Not more voltage, but more power. Stick a wire between the positive & negative terminals to see how much power that battery can discharge quickly. :lol:
It wouldn't be legal in blinky racing, up in open classes could it be legal? Most every competitive esc has a method to program several things like base timing, boost, abs braking, etc. usually through a separate programming card with a cable, or the power button cable with the programming button on the side or a phone app or something. The question is, could that signal modify the esc timing on demand? Can EdgeTX duplicate that signal? If it can duplicate the signal then a separate channel that plugs into the programming spot could be used for a timing advance. Generally the timing is set for the duration of the race, right? Base timing & boost, or whatever profile the esc has for getting 'optimum' performance is set to the maximum that survives the whole race. It may not be the highest performance because that would overheat the motor. So a driver willing to risk a bit might enable the higher performance setting with the heat risk for a 'push to pass' moment. On a side note, if EdgeTX and the MT12 could duplicate the ESC programming cards, either through a new channel or even the aux port on the radio, That could help a lot of people with older ESCs that the programming card has been lost to keep the ESC alive and usefull. A transmitter that can (in the 4 in 1 version) bind to 70+ recievers, AND replace any ESC programming card you have would be a thing of beauty. |
Still getting familiar with the radio and this forum with YouTube has helped a lot. Is the red wire for the receiver an antennae? Wondering what receiver to get for my 5th scale
|
| All times are GMT -7. It is currently 05:17 AM. |
Powered By: vBulletin v3.9.3.9 Patch Level 3
Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.