olliw42 / mLRS

2.4 GHz & 915/868 MHz & 433 MHz/70 cm LoRa based telemetry and radio link for remote controlled vehicles
GNU General Public License v3.0
266 stars 55 forks source link

Add RadioMaster BR3 #170

Closed jlpoltrack closed 2 months ago

jlpoltrack commented 2 months ago

image

olliw42 commented 2 months ago

can't it be a generic layout? I'm really not fond of adding it as "selected device". First, we do have already plenty. Second, it's antenna diversity, and thus a bit clumsy and non-ideal (and expensive) to really promote.

jlpoltrack commented 2 months ago

can't it be a generic layout?

It has a unique target in ELRS, but am fine to update hal and device_conf so that it lives in the 'generic' section if that's what you're thinking.

olliw42 commented 2 months ago

how unique is the layout as compare to a generic layout?

jlpoltrack commented 2 months ago

how unique is the layout as compare to a generic layout?

Somewhat different:

olliw42 commented 2 months ago

many thx

hm, I think we need to think about what we want to do with the situation, to me it seems that the generic concept doesn't really work out, there seem to be way too many exceptions ... I'm not sure if we shouldn't just create a firmware for any device out there ...

tmcadam commented 2 months ago

In response to some earlier comments.

I am in favor of supporting as many targets as possible, even if they aren't ideal, in terms of output power, pins etc.

I don't think we should build for every model of device, but focus on the classes of device. We are doing a mixture now. Could the documents have a table of some sort that links hardware to the correct firmware to use?

Hardware Firmware Version Tested Notes
RX - Radiomaster RP1 rx-generic-2400.bin Y Not suitable for long range, 50mw max power
RX - BAYCK Nano Pro rx-generic-900-pa.bin Y 500mW, good long range option
RX - iFlight 915Mhz 500mw rx-generic-900-pa.bin N
jlpoltrack commented 2 months ago

I would propose an alternative :) since the above approach would require a rather large table to be maintained in the Docs (I think we now support over 50 boards).

olliw42 commented 2 months ago

interesting ideas so I'll add my thoughts

I think the mixture of different "classes" will just be confusing to any users, if they are not pretty much self explaining. IMHO the docs and the repo are linked in that the suitable pre-compiled binary should be easy to find and identify. So far, the idea was to have only generic, and very few selected devices, with implication that there would be only few pre-compiled files with device names, and all other with generic in their name.

However things like BR3 adds a new variety, and it IMHO really makes it hard to understand why for some device one should have to look up a list to find the corresponding generic file while for others one just has to look for the name, among which some are selected and some are not.

This made me think that we should go to simply generate named pre-compiled binaries for basically every device. Could be added by hand, since the current approach does allow already to use one hal file for multiple devices or use some automated approach. The doc could also be automated, or even simpler, in the doc only the selected are explicitely mentioned and for the other it is simply said to look into the folder and pick the correct one.

Either way, I would not add info like tested/not tested, since this most likely will be just a mometary thing, since we likely won't be able to retest em all with every firmware update,

olliw42 commented 2 months ago

I think this PR should not to be postponed until the above discussion is settled, but can go in once the merge conflicts are resolved (and mybe the device name adapted) :)

jlpoltrack commented 2 months ago

Merge conflicts now resolved. BR3 entries in the generic section.

olliw42 commented 2 months ago

just two tiny nit picks otherwise lgtm

olliw42 commented 2 months ago

MANY THX !!