Bemused by FixedID

I have seen posts where people claim to have solved the problem by changing FixedID "from 6 to 5 digits"; others where they "worked better" by changing from FixedID so-and-so to So-and-So. With the 7E, I have tried to steer clear of this by always choosing "None". But the questions linger:
1. Is there any correspondence between the FixedID set in the model.ini file and something eventually stored in the physical model itself?
2. Are there any rules or recommendations regarding the setting of the parameter?

What fixed ID does depends on the protocol. It's intended to be used for model match type facilities, but not all protocols support it, and it doesn't necessarily work the same way in all protocols. If you're not familiar with it, the idea is that the model will only connect to the transmitter whose ID it has stored, and you have to do "something special" (bind plugs or something else odd at power on) to use a different transmitter; likewise the transmitter won't work unless it's connected to the right model. This is a major safety win.

So it gets used for binding. Some protocols also use it for computing the sequence for frequency hopping. Since we don't have access to official sources, documentation or standards, these things are guesses based on analysing the interactions between the CPU and RF modules. As such, we may miss some of the possibilities, so that things like length, parity, who knows what can trigger bugs if they were used and we missed it.

Unfortunately, how and what works best will depend on the protocol, so there's no "best practice" for these things. Since the toy manufacturers tweak protocols apparently randomly, it may change between models. And the hobby protocols that license their technology can have different compliant implementations as well as clones, so they aren't immune to that problem either.

Thank you for the essential, contextual information needed to understand the topic. If the PC world had taken the same enlightened approach regarding the standardization of interfaces, personal computing would still be in the Dark Ages; that is where RC equipment manufacturers apparently prefer to be.

vmsda wrote: . If the PC world had taken the same enlightened approach regarding the standardization of interfaces, personal computing would still be in the Dark Ages; that is where RC equipment manufacturers apparently prefer to be.

It's actually the other way around, started out everything was the same (on 27mhz, as long as the XTAL was correct any tx brand could fly and rx brand). As digital 2.4ghz systems came out everyone started to develop their own proprietary protocols and the standard was lost. Now days no one wants to share their secrets...

vmsda wrote: If the PC world had taken the same enlightened approach regarding the standardization of interfaces, personal computing would still be in the Dark Ages; that is where RC equipment manufacturers apparently prefer to be.

Sorry, but you just hit a sore spot with me, so I'm going to rant a bit about it.

You are wrong on both counts.

First, the analogy is wrong. The protocols - and in particular the fixed id stuff - aren't part of the "user interface", they are part of the internal API's of the hardware. When you look at internal interfaces on PCs, you find things are no better than they are in the RC market. All the major players have different APIs that don't interoperate with each other. There are even equivalents to deviation, reverse engineering the APIs so you can run programs meant for one system on another with an appropriate shim - though Oracle is working on making that illegal. Nuts, the reason that Linux was so successful is because the Unix community was busy infighting and hampering itself rather than cooperating the way you imply. The actual user interfaces for transmitters tend to be very similar - two sticks, some switches and/or buttons and an LCD display. Configuration is different, but that's also true in the desktop market.

The internet started out valuing interoperability, but then the web turned it into a real market instead of an academic playground. The browser/server manufacturers turned HTML from a markup language into a page description language, each adding their own extensions, creating a tarpit in the 90s that the web still hasn't recovered from.

Second, the popular desktops are stuck in the dark ages as far as user interfaces go. You can't get away from the antiquated, wasteful "overlapping windows" mataphor on either Windows or the Mac. Apple created this metaphor with the original Mac, and it was designed for a time when most people used a computer infrequently during the day. That's not what modern computer usage is like, so the fundamental assumptions behind that design are invalid. Which is why I run Unix on my desktop - I can replace the PoS that ships with the system with a modern dynamic window manager, which makes more efficient use of the limited number of pixels on my desktop. It also means I spend basically no time adjusting window geometry - my window manager takes care of` that. The exceptions are the few applications that just break if you don't give them that metaphor. And the web just makes things worse.

Bottom line - the RC technology is no worse that personal computing technology, or anything else that depends on modern computer facilities. They all suck. They inspired my addendum to Clark's quote about "any sufficiently advanced technology is indistinguishable from magic": "it only works for highly trained wizards and even then is flaky and unreliable."

Cereal-Killer in post #48491 gave a stellar example of the present state of affairs. I used the expression "standardization of interfaces" rather too loosely - but rant away, I am not overly sensitive. In my 26 years as an IBM systems engineer I knew a thing or two about proprietary stuff, so computing at home has followed Open Source solutions for as long as I can remember (no Windows or Mac in sight).
This hobby has a very steep learning curve. Deviationtx is important for a beginner because it simplifies one aspect of that process, enabling us to try various types of equipment under one umbrella. But I do resent having to spend precious time with soldiering iron in hand.