I would hide the “3 addresses” from the user
Basically every remote would get the same addresses like you already do, by copying the conf-string 1:1
Then, the remote “number” (0,1,2) just adds this amount to the address
The Rx checks if it gets messages to its “base” address and the +1 and +2 variant
Therefore the setup and code on the Tx stays like it is now, just duplicate configs
Now how to “number” the remotes I was thinking either by long-press right (free button on the remote) will switch the “channel/remote number” like in a walkie talkie or like with nintendo contollers
((OR the remote just listens at wake up, if someone is already transmitting at the base address, then increments by 1 or 2, depending, so it would be fully automatic))
While this obviously changes code on the remote now, it leaves the RF part original and only touches the UI part, which I prefer since it is easier to test
Alternatively for now the user could just manually add 1 or 2 to the address in the config after copying the string since 75% the time he will have to force config anyways by altering this value too
I will sleep on your and my idea and implement one of them in the next days
I guess it is.
Adding 1 is a little harder in hex, which is the representation the address is in
++0x9F = 0xA0 and so on
But one could just add a “+1” and “+2” button next to the field in the config tool
Or just make a simple webtool that takes a config string, sets the cal_ok = 0 and increment the address by 1 or 2 for this specific purpose
Guys, I went a hybrid way (Jan's own-address idea + Ludwig's Rx answering each remote). This published version is available for study and testing here: github.com/monterman/BREmote-V2/tree/multi-tx. Open to comments. ALPHA, not water tested, it's more of a bench test version (I will try myself soon). Design and safety rules are in docs/MULTI_TX_DESIGN.md, and the how-to is in docs/MULTI_TX_GUIDE.md.
Since my Evo branch required flashing of both, this MultiTx also requires it: the Rx and every Tx get the new firmware, and all remotes get re-paired once, in one pairing window. Back up your ?conf first. The other settings carry over.
Heads up: it's coded and passes the tests on the PC, but it's not tested on hardware yet. I don't have time to test it ATM since I'm working on the FM stations, so if anyone wants to bench test it, or just read it and poke holes in it, I'd appreciate the feedback.
I've been working hard on the multi Tx scenarios, mainly design until today, when I decided to code it for sharing. There are quite a few scenarios covered, each with its own rules, and there's a master and slave 1, slave 2 setup for buggy (Rx) control. All of this is needed for safety, so in short the safety philosophy is expanded to more than one remote. It also allows FM and RTM with multi Tx, plus a summon: the other remote can call the buggy to itself. The full rules are all on GitHub, open source under the GPL-3.0 like the rest of BREmote, so here's just a summary:
Every remote has its own ID from its chip. Packets stay 6 bytes, and bytes 0-2 are remote ID XOR buggy ID, so a remote can only drive the buggy it was paired with.
The first remote paired is the master, the others are slaves (built for up to 4 remotes; the bench plan covers 2 for now).
One remote in control at a time. The other one shows E9 and its trigger does nothing. The motors keep running for whoever is in control.
Only the remote in control keeps the motors alive. If it goes silent, the failsafe stops the motors, same as today. The other remote can't keep them running.
No timer takes control away, and no timer kills FM or RTM. If the remote in control goes silent for 10 s (or sits at zero for 10 s with FM/RTM off), another remote can take over, but only on purpose: squeeze from zero, or do its own RTM/FM gesture to summon the buggy to itself.
A takeover always starts from zero, with a 25 % limit ramping to full in 4 s, since the buggy could be near the other rider.
The master can take control back (zero throttle, RIGHT tap then RIGHT hold 1.2 s), but not while FM/RTM is armed. A slave can never take it from a master who is driving.
FM, RTM and summon follow the GPS of the remote in control, so any Tx that wants them needs its own GPS fix. A Tx without GPS still works, manual only.
If a gesture can't engage, the remote shows St. If you try to take over while the other remote is busy, it shows E9.
A spare remote nobody touches locks itself after 120 s. Idle remotes send slower to stay inside the EU 10 % duty.
With only one remote paired, nothing changes.
Before testing:
Bench first, props off, one buggy at a time.
If you ever copied a config between receivers, two buggies can answer the same remote (that's true with today's firmware too). Check that no two receivers show the same own_address in ?conf, and never power two buggies during a test.
no_lock = 1 also turns off the spare remote auto-lock.
Pair the remote you ride with first, at arm's length. The pairing distance gate is calculated, not measured yet.
Thanks Jan and Ludwig for the ideas. Post results or problems here or on GitHub.
Nice one Ludwig!
I liked your E1/E2/E3 so I put it in my multi-tx branch too.
Mine now shows E1, E2, E3 (and E4, since I allow up to 4 remotes) instead of the old E9.
That way the other rider sees which remote is in control. Thanks!
