"Tinkering" platform

[Scout]

I've got access to a variety of surplus powerchairs. I'd like to "tinker" with the control system (particularly the UI) on one -- to explore other design possibilities.

Ideally, I'd like to be able to augment (or replace) an existing UI device with my prototype without having to mess around with the rest of the chair. In particular, I'd like to be able to retrofit my prototype to a "real" user's compatible chair without putting that asset at risk -- or, compromising the user's safety!

(One approach is to leave the existing UI in place as a "fallback" if mine "surprises" the user in some unexpected way)

This begs a few questions:

• a suitable/commonplace chair (silly to pick something that only 1 in 1000 users drive as I'd be unlikely to later find such a suitable USER!)
• ability to augment the existing control (I know there are "walk behind" controllers available for some chairs)
• ability to query and alter "programming" parameters from the UI device's electrical interface (even if the UI device is unable to normally do that)

[woodygb]

So what improvements do you envisage that your UI will have over a standard UI and what exactly are you defining a UI as ?

Oh ...and please add a general world location to your profile .

[woodygb]

ability to query and alter "programming" parameters from the UI device's electrical interface (even if the UI device is unable to normally do that)

That's not going to happen unless you know or can crack the existing control systems communication protocol.

[Scout]

ability to query and alter "programming" parameters from the UI device's electrical interface (even if the UI device is unable to normally do that)

That's not going to happen unless you know or can crack the existing control systems communication protocol.

That;s not a problem -- I do that sort of thing for a living.

I assumed the easiest approach would be to find a suitable chair (see my previous criteria). Then, reverse engineer the "normal operation" protocol with the chair's controller.

At that point, I should be able to mimic the original UI, detect error codes reported by the chair's controller, etc. (because I will have observed how each of these things are handled... within reason)

Next, find a programmer for that chair. Then, reverse engineer the protocol used by the programmer to talk to/with the chair.

At this point, I can mimic that protocol to extract the "current settings" from any similar chair and store them in "my device".

Then, overwrite them with settings that I deem appropriate to use with "my device". And, evaluate my device as applied to that chair.

Finally, when "my device" is going to be removed and replaced with the "original" UI, jam the preserved original settings back into the chair's controller (so "my device" looks like it was never there!)

Note that this also allows me to insert "my device" in series with the existing UI. That UI would think that all was well (because my device would pretend to be the chair's controller, when viewed from the connector to that UI). And, if the user felt the need to override my device by actuating the original UI, then my device could pass the inputs from the original control through instead of the current "commands" that my device thinks are appropriate.

[Note that there is a catch-22, here -- how do you differentiate between an "idle" original UI and a user wanting to stop the chair using the original UI?]

The technology isn't the hard part. Rather, its deciding where to spend my efforts so I don't end up with a solution that only is applicable to some odd-ball chair that no one (no one to whom I have easy access) drives!

[Burgerman]

I would look for any chair with r-net as a control system.

The software is easy to get.

[LROBBINS]

Both the R-Net and the upper-end dynamic systems are CANbus variants, so, if you figure out their dictionaries, you should be able to add a separate module with whatever UI protocol you want without removing any of the original pieces.

[woodygb]

I assumed the easiest approach would be to find a suitable chair (see my previous criteria). Then, reverse engineer the "normal operation" protocol with the chair's controller.

OK...You have made an understandable error by using a chair type as your common denominator .
In general there are 3 major control systems providers to the wheelchair manufacturers ... John mentioned R-net made by PGDT ( Curtiss-Wright ) and indeed you will find this control system used by a range of wheelchair manufactures.
You also have 2 other major control system suppliers Dynamic ( Invacare ) and Quantum Q-logic/ Pride /aka Curtis .

http://www.cw-industrialgroup.com/About ... ology.aspx

https://dynamiccontrols.com/en/

http://www.quantumrehab.com/quantum-ele ... system.asp
https://www.curtisag.ch/en/unsere-produkte/

[Scout]

I would look for any chair with r-net as a control system.

The software is easy to get.

Do all R-net "powered" chairs roughly conform to a single model for control (i.e., this is the algorithm to control a powerchair based on 2 drive motors and a UI device)? More generally, do ALL chairs roughly conform to a single control model? (I'm unhappy with my phrasing of that...)

E.g., UI device (typ joystick) feeding a motor controller with additional "modules" for things like tilt, recline, lights, etc.

Or, does each manufacturer approach the design problem with their own particular insights (and/or gimmicks)?

For example, most chairs (that I've CASUALLY seen) use an XLR connector as a charging port and that is located either on the "joystick" or battery box. A few have had on-board chargers (so, just an AC power cord dangling off to the side). They've all seemed to have a motor controller located close to the battery box and the battery box located close to the motors (obvious reasons).

Do, for example, the joysticks have any smarts (beyond what is needed to interface to the motor controller)? And, presumably, the motor control profiles are handled by the motor controller (NOT a "smart" UI module talking to a "dumb" motor controller)?

[Scout]

I assumed the easiest approach would be to find a suitable chair (see my previous criteria). Then, reverse engineer the "normal operation" protocol with the chair's controller.

OK...You have made an understandable error by using a chair type as your common denominator .

It was (and remains) very deliberate. I'm not designing a "product". All I need is a chair to which I can fit experimental UI's. I'll have to send a request to some folks to find me a particular make/model of a relatively "common" chair (hence the reason for the question), pull the electronics off of it and mail them to me (not even the motors!). I can then mock up a "chair emulator" (so the electronics THINK they are controlling a real chair) while I sort out what's happening inside.

At a later date, I will want a real chair (of that make/model -- or something compatible from the standpoint of the control electronics/software) to play with my UI concepts.

Finally, I will want to find a local "driver" who uses that make/model (or compatible) chair to get their comments on my UI concepts.

If I send off a request for "the electronics off any old chair you have lying around", then there's no guarantee that I'll receive something that is commonplace enough to support the next two "steps" in the above sequence. The chair the electronics were stripped from will be gone (so I can't fit the electronics back onto it to do my own evaluation when the time comes). And, the chances of finding someone who drives THAT particular chair could be reduced.

Better to know a more common chair and be able to say "find me a model XYZ -- they should be relatively commonplace!"

In general there are 3 major control systems providers to the wheelchair manufacturers ... John mentioned R-net made by PGDT ( Curtiss-Wright ) and indeed you will find this control system used by a range of wheelchair manufactures.
You also have 2 other major control system suppliers Dynamic ( Invacare ) and Quantum Q-logic/ Pride /aka Curtis .

http://www.cw-industrialgroup.com/About ... ology.aspx
https://dynamiccontrols.com/en/
http://www.quantumrehab.com/quantum-ele ... system.asp
https://www.curtisag.ch/en/unsere-produkte/

But, I can't ask untrained folks to "find me a chair with an R-net controller" (unless R-net chairs proudly announce "R-net inside" -- like "Intel Inside" -- on their bodies).

[Thx for the links; I'll chase them down to see what I can learn!]

[woodygb]

Each control system manufacturer has their own proprietary code and each differing control system type from the said manufacturer also has a different communication protocol and code... Serial , RS485 & CAN bus to name the few that I know of.

Dynamic joysticks.... as I recall .... have a brain of sorts and need to be matched to the controller.


http://www.electricwheelchairparts.com/ ... ation1.htm

[Burgerman]

I just ordered a chair. On the order form there is a choice of VR2 system, or R-net, or Dynamic. Dynamic has around half a dozen different joysticks, and various different power modules as a system that works together. R-net has similar, in my case I ordered an advanvced colour joystick, with infra red control for TVs etc. And a 120Amp R-net power module. You tick the correct box on the form. It turns up with those options.

As such you can find the same chair with around 3 different manufacturers control systems, which may have various different power modules, or any of about 15 joysticks fitted. You need to know what you are looking for when you buy a used chair.

As I look around my room right now, I see three chairs. One is 100A pilot plus. One is 120A R-net. One is 150A roboteq... And in my kitchen is a chair with a Dynamic brushless controller power module with a dynamic REM24 joystick.

[ex-Gooserider]

As mentioned there are a small number of control system makers. The various manufacturers may favor particular control systems, but it is pretty much possible to get any given control system on any given chair make / model, so searching for a particular chair will give only rough odds of getting a given control system....

However, with the notable exception of the Invacare gearless / brushless motors, and some of the Asian folding chairs that also use brushless motors, you can pretty much connect ANY pair of motors to ANY given control system, as long as you use all the parts from the same system...

The systems almost all consist of, at a minimum, a motor (or power) control module, and a joystick module, and the cabling between them. The batteries are interchangeable, as long as they are 24V, and the motors are interchangeable as long as they are brushed and you have access to the programming software. You may need to adjust the voltage for the brake coils (some are 24V, some are 12V) and tune the "motor compensation" value (don't mess with this unless you UNDERSTAND what it is and how it works - it is the only programming parameter that has really serious potential for hurting one, as it can cause a 'runaway' if set wrong)

There are some cheap, low power systems that combine the joystick and power modules into one unit.

In some chairs the joystick can be replaced by alternative input units like switch arrays, sip & puff units., etc.

In addition to the two main modules mentioned above, you may have added modules for things like seating functions, attendant controls, etc.

The different control system manufacturers have different interfaces, both physical and electronic, and vary in how / where they store the 'brains' and programming information for their hardware.

Thus you can NOT mix and match parts between control systems, although a given system may have multiple parts to choose from for a given function. For example there are several different R-net joysticks - which are more or less interchangeable, possibly with programming changes, but you can't use any joystick that is not "R-net compatible"

R-net software is readily available, but it also requires an expensive and hard to get 'dongle' to actually change the programming in a chair.

P&G Pilot+ gear is obsolete and only available on Ebay, etc. but the programming software and cable is very easy to get.

ex-Gooserider

[Scout]

As such you can find the same chair with around 3 different manufacturers control systems,

That is unfortunate (for me). As I suggested up-thread, I doubt the chairs proudly announce their control systems ON the body of the chair (esp if the controls can vary for a given chair "chassis").

So, I'm stuck trying to give someone directions as to what I need/want without being able to unequivocally say, "Yes, if you get me one of these, there will be no question that you got the RIGHT THING." Keep in mind, I have to rely on personal favors to get these things; folks won't be too happy if they strip a chair and mail me the kit only to discover that I'm "disappointed" -- cuz they got the wrong thing! ("No, I'm not going to try again. Do it yourself when you're back in town!")

Is there a chair (or manufacturer) that doesn't offer this flexibility in choice of control systems? E.g., if you wanted a Betamax VCR, buying from Sony was a pretty reliable way of ensuring that you got just that!

which may have various different power modules, or any of about 15 joysticks fitted.

None of that should matter (least of all the joystick/UI device) if they are all compatible with their counterparts ON THAT CHAIR

You need to know what you are looking for when you buy a used chair.

But, I'm not buying a chair. Rather, looking to get access to a chair to tinker (actually, THREE instances of the same/similar chair). Silly to invest money in a disposable prototype esp given that this isn't a revenue-generating exercise!

This is further complicated by my need to pare the "chair" down to "a pile of electronics" (sans mechanism) to make development easier; yet, to be able to later have the complete chair (to make "alpha" testing practical). Finally, to ensure my efforts can be "ported" to a real user's chair for their ("beta") testing.

[I don't imagine a user would want to tinker around in a "foreign" chair and be expected to comment about the (controls) experience in a way that they could directly correlate with their learned experiences in their "normal" chair -- how much of the difference they experience in the foreign chair is a consequence of the chair vs. the changes I've made?]

[woodygb]

So, I'm stuck trying to give someone directions as to what I need/want without being able to unequivocally say, "Yes, if you get me one of these, there will be no question that you got the RIGHT THING."

Yup ...That's how it is and you are stuck with it.

[Scout]

In some chairs the joystick can be replaced by alternative input units like switch arrays, sip & puff units., etc.

In addition to the two main modules mentioned above, you may have added modules for things like seating functions, attendant controls, etc.

So, there is nothing inherently restricting a certain class of "options" to one control-system-type or another? I.e., I can't say "find me a chair that supports lift" and use that as a crude indicator that the chair will have a _______ control system? (I assume it would be easier for an unskilled person to recognize a lift mechanism and/or controls than to recognize a particular brand of joystick+motor controller on a chair with none of these "options")

The different control system manufacturers have different interfaces, both physical and electronic,

I don't imagine any would resort to just a pair of UI signals labeled "forward/reverse" and "left/right". So, I expect to encounter a microcontroller in any UI device if only to act as a small/simple/inexpensive mechanism for converting user actions into suitable signals to be communicated to the motor controller (and, to report conditions from the motor controller/battery back to the user in a form appropriate for the indicators on that particular UI device). But, this requires very little in terms of "smarts".

and vary in how / where they store the 'brains' and programming information for their hardware.

This is the more significant issue -- the control model implemented in the chair. The physical UI device might contain all of the algorithms to drive the chair and the motor controller simply acts as the "muscle" (i.e., brawn without brains). Or, the UI device may just be a sort of peripheral that interacts with brains (and muscle!) in the motor controller. Or, some combination of the two -- or even a third possibility, entirely.

My goal would be to have everything in the UI device (motor controller acting purely as muscle) so I don't have to guess as to how the cascaded control systems are going to interact. And, to do this by "programming" any smarts in the motor controller to be as close to "dumb" as possible (i.e., protect the motors -- in case the UI tells them to do something "stupid" -- but, otherwise, let the UI decide just how they should be driven)

Thus you can NOT mix and match parts between control systems, although a given system may have multiple parts to choose from for a given function. For example there are several different R-net joysticks - which are more or less interchangeable, possibly with programming changes, but you can't use any joystick that is not "R-net compatible"

That wouldn't be a goal. I just want to experiment with different ways of conveying a human's needs/desires to a chair. I intend to equip exactly one such chair (so no need to evaluate the given UI approach with a different manufacturer's controls!)

R-net software is readily available, but it also requires an expensive and hard to get 'dongle' to actually change the programming in a chair.

Is this because the dongle is overpriced (due to low manufacturing quantities/demand and no effective competition)? Or, an intentional attempt at making "programming" a separate "profit center" (by deliberately making the tools more expensive than necessary)? Does anyone know what's in the dongle or is it a potted assembly?

E.g., OBD tools for automobiles were initially very expensive -- because they were sourced by just a few firms. Now, you can buy/make yourself for very little money (because demand has increased as well as the number of viable suppliers).

[Scout]

So, I'm stuck trying to give someone directions as to what I need/want without being able to unequivocally say, "Yes, if you get me one of these, there will be no question that you got the RIGHT THING."

Yup ...That's how it is and you are stuck with it.

So, a smarter approach might be to locate the eventual "local user" and then use information about their chair to drive my choice of control system and prototype chair acquisitions. Cut the risk factor (relying on others to strip the electronics out of a chair) out of the process. That's probably safer but means I can't really do much work until I have physical access to the supply of surplus chairs. (so, "starting" the project is delayed instead of just the eventual "beta" test) But, the up side is that I can be far more aggressive/destructive in my deciphering of their implementation! (i.e., pick a couple of sets of kit so I can literally tear them apart instead of trying to carefully disassemble while taking pains to preserve their functionality)

[LROBBINS]

My goal would be to have everything in the UI device (motor controller acting purely as muscle) so I don't have to guess as to how the cascaded control systems are going to interact. And, to do this by "programming" any smarts in the motor controller to be as close to "dumb" as possible (i.e., protect the motors -- in case the UI tells them to do something "stupid" -- but, otherwise, let the UI decide just how they should be driven)

Then take a look at the Dynamic DX series because that's their approach - the smarts are in the "remote" and the brawn is in the "power module". However, do note that their CAN bus variant is proprietary. However, the software is readily available and a dongle-less patch for OEM or even engineering level programming can be had.

[Scout]

My goal would be to have everything in the UI device (motor controller acting purely as muscle) so I don't have to guess as to how the cascaded control systems are going to interact. And, to do this by "programming" any smarts in the motor controller to be as close to "dumb" as possible (i.e., protect the motors -- in case the UI tells them to do something "stupid" -- but, otherwise, let the UI decide just how they should be driven)

Then take a look at the Dynamic DX series because that's their approach - the smarts are in the "remote" and the brawn is in the "power module".

So, one can "program" a chair just by having access to the "remote" (there is nothing that resides in the power module that differentiates it, at any time in its life, from any other power module of the same make/model)?

Is the power module "commanded" with low level messages like "set current to X" (for torque control) or "set voltage to X" (for speed control)? And, correspondingly reports back EMF (indicative of speed) or current (indicative of load)? I.e., how does the "remote" close the control loop? (or, are some of the brains still inside the "power module")

However, do note that their CAN bus variant is proprietary. However, the software is readily available and a dongle-less patch for OEM or even engineering level programming can be had.

That will just look like another/different communications protocol; the real issue is always deducing the actual higher level (i.e., OSI 7) protocol that they are layering on the lower (data/link) level protocol.

But, from other comments, here, it seems the bigger problem is logistical -- getting "development hardware" to reverse engineer that will be compatible with a "prototype chair" to evaluate the design(s) and, ultimately, a user+chair to make a more learned evaluation of the same electronics system.

[LROBBINS]

or, are some of the brains still inside the "power module"

Yes. And, given that no one has "cracked" the Dynamic DX CAN frames, I have no idea what instructions are going from the remote to the power module, but most likely they are mostly throttle = x, steering = y but lots of hand-shaking as well. Dynamic did have a patent or two on their systems, so there may be some modification of the basic (low-level) CAN protocol as well.

[Scout]

or, are some of the brains still inside the "power module"

Yes. And, given that no one has "cracked" the Dynamic DX CAN frames,

Is that because no one has made a serious effort? Or, not had the right skillset/toolkit? Or, have the DX folks gone to deliberate lengths to obfuscate their design? (if so, why?)

I have no idea what instructions are going from the remote to the power module, but most likely they are mostly throttle = x, steering = y but lots of hand-shaking as well. Dynamic did have a patent or two on their systems, so there may be some modification of the basic (low-level) CAN protocol as well.

The hand-shaking could just be status updates to ensure the power module isn't running off the rails (and needing to be commanded off). Or, the failsafes in the power module needing to be reassured that the remote (UI/brains/controller) is still alive and functional/sane.

I would assume the PWM (if a DC motor) is handled internal to the power module with the "setpoint" provided by the "remote". Or, the commutation performed there in the case of a BLDC.

Are there any detailed photos of the internals of these devices? (I assume a detailed service manual would be fantasy)

[woodygb]

You might find this thread interesting.
R-net
https://www.wheelchairdriver.com/board/ ... f=2&t=6533

Dynamic Shark thread.
https://www.wheelchairdriver.com/board/ ... f=2&t=6503

Pilot+ here ...
http://dzlsevilgeniuslair.blogspot.co.u ... drive.html

[Scout]

You might find this thread interesting. [...]

It seems like the data obtained for each is acquired by just passively (?) observing traffic on the wire (?). Has anyone taken a more aggressive look at any of their "guts"?

[woodygb]

Some of the components and their function have been identified / investigated .

With many joysticks it would appear that the function is to "simply" convert the joystick or momentary button pushes output into a signal .
There will also be an led bank/s that display ... via a feedback signal.... the current status of the main control module and the external components that are plugged into it.

Note:- I'm currently baffled by your approach ...but attempting to help.

I'd like to suggest that you try and grab ANY cheap or free chair of ANY type make or model and have a quick poke around .

[Scout]

Note:- I'm currently baffled by your approach ...but attempting to help.

What aspect of it? The fact that I want/need "three" copies of the same "platform"? (note that I don't drive a chair so don't have space already set aside for one! I also travel a bit and don't want to have to lug a complete chair from point A to point B to continue my research/work when all I really need is the "joystick" and "motor controller" to explore how it works). OTOH, once I have a good idea and have knocked up some prototype electronics, I'll want to see how it actually affects "driving" the chair -- which means a need for a complete chair (whether I'm at point A, B or even C!).

I'd like to suggest that you try and grab ANY cheap or free chair of ANY type make or model and have a quick poke around .

I've looked at several on the way to the tip. That's how I know the general design approach. But, I've never bothered to make note of which microcontroller(s) are used in each module, whether there are "house" parts used, if there are any hidden diagnostic/programming (for the MCU) ports (serial, JTAG), which/any socketed parts to make tinkering easier. Etc.

E.g., it would be a LOT easier (and far more "authoritative") to dump the code from an MCU than it would be to try and guess what's inside by limiting yourself to ONLY examining the comms that it CHOOSES to show you.

[woodygb]

The "problem" you have explaining things to the majority of us is ...
We mostly have a mechanical bent / engineering background. ... Electrickery and electronics are black magic and voodoo.
I myself am self taught in coding and electronics and have a VERY NARROW / INCOMPLETE understanding of what everything does.

[Scout]

The "problem" you have explaining things to the majority of us is ...
We mostly have a mechanical bent / engineering background. ... Electrickery and electronics are black magic and voodoo.
I myself am self taught in coding and electronics and have a VERY NARROW / INCOMPLETE understanding of what everything does.

OK, my bad.

Let's assume these devices (motor controllers, joystick modules, etc.) are inexpensive and compact enough to preclude using "computers" (in the sense of "PCs") in their implementations. Yet, they would obviously benefit from having computer-IZED electronics (instead of a mess of discrete electronics).

So, its reasonable to expect microcontrollers (MCU's) to provide the "smarts". Each is essentially a microprocessor (MPU) with "permanent" program and "alterable" data memory contained entirely within (instead of as external components like in a PC).

Somehow, the "program memory" has to be "programmed" with the software ("firmware") to give the microcontroller the functionality desired. E.g., the MCU in the joystick module needs to have a "program" installed inside it that makes it act like a "joystick module" (whatever THAT is!).

You can purchase MCU's that have been preprogrammed (by the MCU manufacturer) to contain "your" program. The MCU manufacturer will typically mark these components with a "house number" (part number) of your choosing -- to make it easier for your manufacturing guys to assemble them into "joystick modules". This might be the only part number marking on the component -- which obfuscates your choice of components to your competitors (or, folks like us!). To a casual observer, the MCU looks like a "custom" chip -- one that can only be purchased from you, the joystick manufacturer IF you even offer it as a "spare part" (doubtful... you'll just sell completed joysticks!).

For most MCU customers, they purchase "blank" MCU's from the MCU manufacturer and "program" them on the assembly line as whatever product USING THEM is being manufactured (e.g., joystick modules). This takes time (labor) and a bit of kit (the "programmer"). If your quantities are high enough, you might opt to just let the MCU manufacturer do this FOR you and sell you "preprogrammed" MCU's.

The down-side of a preprogrammed MCU is that it deprives you of some flexibility -- you have to decide how many of each "program" you want ahead of time; an MCU programmed for a joystick module won't work in a motor controller module (even if they use the exact same MCU!). Also, you can't make changes to your software (program) as easily as those changes have to be shipped off to the MCU manufacturer to be incorporated into the next batch of preprogrammed MCUs that you'll purchase (and they may charge you a fee to make the change). Of course, any MCU's that you have with the "old" software preprogrammed into them are now of dubious value (if you are making a change to the program, that suggests that there is something "wrong" with the current version!).

So, most devices manufactured with MCU's inside are designed for the device manufacturer to do the programming (NOT the MCU manufacturer).

You can design the circuit board to install a "chip socket" for the MCU so that the board can be built and the MCU installed AFTER it has been programmed. This lets you manufacture the boards and postpone adding the MCU until the last minute. But, this adds the cost of a socket to the design. OTOH, you can install a special MCU that has been programmed with a "test program" that allows folks on the assembly line to verify the proper operation of the circuit board. Once the operation has been verified, you can remove the "special" MCU and be reasonably certain that the tested board will function properly when the real MCU is installed.

You can also design the circuit so that you can program the BLANK MCU after it has been soldered onto the circuit board! You can still postpone the (final!) programming until the last moment (e.g., just before you ship the device to your customer so you can be sure to have the latest and greatest software available!) You'll still want some way of testing the circuit board to verify proper assembly, no defective components, etc. You can do this by programming a "test program" into the MCU, performing the "manufacturing test procedures" to verify proper operation, then replacing the "test program" with the "real" program. Or, you can build the test program into your "real program" and activate it via some magical sequence of events (that likely won't be encountered by the normal user). E.g., ground pin X on component Y while applying power (especially if pin X is not normally accessible to the end user!)

Given that you can program the MCU "in circuit", you need a way of verifying that the "program" (firmware) that you've installed is actually present in the device. So, you want a way to "read back" the contents of that "program memory" as part of the verification phase of the programming operation. I.e., "Location 0000 is supposed to have a '27' stored in it. Does it? If so, let's move on and check location 0001. If not, then this MCU is obviously not going to perform as we'd intended cuz that 'instruction' is incorrect!"

Well, if I can "dump" the contents of your MCU, then I can decode the instructions that are represented by all of those bits of data. I can, effectively, recover your original software (firmware). I can then look through it and discover EVERYTHING that it could ever do! Even if I never witnessed it doing any of these things!

Imagine having a transmission for a car that is sealed. You never see the car drive backwards so don't even imagine that it has that capability! OTOH, if you could disassemble the transmission, you'd probably notice mechanisms that appeared to allow it to "run backwards". And, you'd trace linkages to discover how those mechanisms were activated.

Looking at the DISASSEMBLED software for the MCU lets me see what messages it might transfer to other modules. And, identify the conditions that would cause those messages to be transmitted -- even if I never observed them "in the wild". In addition, it lets me see what the components of each of those messages are and what they "mean". This gives me clues as to what other modules receiving those messages might be doing (why would I need to convey this piece of information to another module? and, which module is it intended for??)

Because this is so easy to do, MCU manufacturers have been tasked (by their customers) with making it "impossible" for folks to "dump" the contents of programmed MCU's. Usually, this is done by adding a step to the programming sequence that allows the device (e.g., joystick module) manufacture to "lock" the MCU after verifying that the program has been installed correctly. Like sealing up that transmission with "special" fasteners (hoping that folks don't have the correct tools to remove them) or even "one way" screws. Or, welding the case shut!

But, most of these locking mechanisms have flaws in their implementation. So, even a locked MCU can often be "dumped". And, sometimes the locks aren't even "set"!

If the item in question is costly to repair/replace, you might be discouraged from tinkering (one product that I worked on sold "spare" components for $2,000 EACH; you didn't casually screw with that component cuz of the cost of replacing it if you broke it). OTOH, if you're a business (competitor), you might think nothing of buying several "units" with the intent of destroying them as you try to "evaluate" them (a competitor of one of the firms I worked with bought ten $5K units with the full intent of "making them valueless" after sorting out how they work).

[Burgerman]

What do you hope to achieve by this?

[Scout]

What do you hope to achieve by this?

It would tell me everything that a "joystick module" (or any other module of interest) could do so that I could emulate it completely with a replacement "user interface module".

Attacking the "motor controller" would similarly tell me everything that the motor controller could do -- so any other module that talked to that would be able to handle those "situations" (instead of throwing up its hands when presented with something "unexpected").

E.g., are you sure you know ALL of the parameters that can be programmed into your chair? Are you sure there isn't a different "manufacturer programmer" that has abilities that even the "OEM programmer" doesn't have? Are you sure that the parameters that you think are present are actually implemented? Or, that they are implemented correctly? If you can examine the code running in the motor controller (and other modules), then you know exactly what data/parameters it uses and how it uses them.

[woodygb]

I'm aware of multiple programming levels .... SERVICE ,DEALER , MANUFACTURER , FACTORY and DEVELOPMENT..

MANUFACTURER is usually the highest level we can obtain.

[Burgerman]

E.g., are you sure you know ALL of the parameters that can be programmed into your chair? Are you sure there isn't a different "manufacturer programmer" that has abilities that even the "OEM programmer" doesn't have?

Yes those exist. I have a dynamic programmer that goes beyond what the OEM can do. But many of those settings are to protect the electrical design, or to prevent reliability issues, or that change things that cause issues with other settings. Or software problems that may cause a runaway etc. And those were fine tuned for reasons we dont understand over time. Or refer to different variants of say a power module with different capabilities. Or even different hardware versions. How can you ever know any of that?