Can you multplex hall encoder signals to save pins

This is kind of off-topic as it relates to multiplexing Hall sensors. It’s tangentially related to SimpleFoc as I’m trying to save pins, to enable a SimpleFoc board to be designed to replace the brushed driver board. I won’t be offended if you delete this post.

The problem:
I have four cheap hall sensors, providing two signals with each. I want to read those encoder signals on a microcontroller (Could be a Teensy, ESP32 RP2040)

We’ll get 11pulse per revolution. ~11 RPM, so something like 121 pulses per min. So about 2hz
there are 8 signals so we need to read at ~16Hz

Can I put these through a Multiplexer to save pins? I’ve read here and here that this produces a mess but also that some have had success with lower speed signals.

Theoretically this is possible but you need to time the multiplexer on the raising edge of the hall signal, which means you need to have a pin to control the multiplexer. Right before you read from the hall sensors, you must high/low whatever the multiplexer needs, redirect the signal, then low/high to get the other signals. You will still need an extra pin to control the multiplexer.

What multiplexer you are using / intend to use? Part? Your multiplexer has time to switch which must be at least a magnitude faster than the fastest (shortest) hall signal. Yeah, Nyquist frequency and all that signal theory mambo but in my experience I’d go for a factor of 10 minimum.

A much more important question is, if you are multiplexing the signals on the same pins, how does SimpleFOC algorithm know which pin at what time is which sensor?

1 Like

Thanks. This seems overly complex. Going to abandon this line of thought and look for alternate ways to save pins

The multiplexing will definitely work, this is nothing new. The real problem would be redirecting the hall sensor input to the SimpleFOC logic, because the constructor expects three inputs.

In terms of multiplexer, it depends a bit on what kind of chip you’re talking about…

a 4-2 binary encoder would lose the information about which Hall was fired, so that would not work…

A 4-1 Multiplexer could work, but would not save any pins as you’d need 2 control pins for it. Also, the logic to control it would be very complex, and rely on you being able to predict which Hall will fire next.

A 3-1 logic circuit made from standard logic components could work better. You could wire it so the Halls produce 3 distinct signals on 2 pins:

No Hall → 0 0
Hall A → 0 1
Hall B → 1 0
Hall C → 1 1

This could work, but you’d have to adapt the code in SimpleFOC’s HallSensor class to handle this kind of input.

1 Like

Thanks both. This idea is officially abandoned. Too much complexity for too little benefit.

Get a bigger MCU?

1 Like

Yes, that’s exactly the solution. If we put a Teensy in the slot then the problem goes away.

What slot? That sounds cryptic.

The microcontroller in this case is in the Sparkfun Micromod format, the problem was the lack of pins on the ESP32. So we just swap MCU to Teensy or RP2040 instead.

This is the robot project once/if the Brushed version works, it would be good to do an alternate version with a SimpleFOC Motor driver board replacing the brushed Motor driver board.

Neither ESP32 nor RP2040 have good ADC. Teensy would be my choice.

1 Like