Pinion Smart.Shift Charge Port | Stuff What I Made

[utterances-bot]

Pinion Smart.Shift Charge Port | Stuff What I Made

I covered in an earlier post that I had retrofitted a Pinion Smart.Shift gearbox to my Deviate Guide. I ended that post mentioning that I had yet to come up with a good solution for accessing the battery charge port, leaving it poking out one of the existing cable holes;...

https://timang.us/2025-01-27-pinion-charge-port/

[SandyThomson]

I assume you couldn't just cut the cable and put a different connector on there? I guess if you're only charging it twice a year it's probably overkill and a bit risky

[timangus]

Sure I could, but the cable splice would become a vulnerable site for water ingress (despite being internal). If I was to go down that route it would probably be better to make up a little adapter loom to go from the existing connector to the new one. But overall probably not worth it, as you say.

[spatcho]

Good day, Different topic : I am interested to get a pinion smart shift bike. It seems it's only possible to see which gear is engaged via the app or via an ebike computer. I don't want ebike and I ride with my phone hidden and I like to see the engaged gear on my bike computer or watch, like with di2 and my garmin. As smart.shift advertise via bluetooth, did you try to read it with a bluetooth sniffer ? I asked pinion for an api, they don't provide it. Best

[timangus]

I have not, no. Even if it does advertise via Bluetooth there is no guarantee that this is all the time; it may only be when the app is connected. That hadn't occurred to me though, I'll have a look next time I remember. What you do with these potential messages is another question; obviously you'd need another device of some kind to capture and rebroadcast in a Garmin friendly protocol. Are you familiar with BT sniffing at all, i.e. what apps to use etc.?

What I'm fairly sure could be made to work is to put a little microcontroller together that connects to the loom, reads the CAN bus messages and rebroadcasts them as appropriate in BT/ANT+/whatever. Both approaches would need a fair bit of reverse engineering of course.

[spatcho]

I would use the app "nrf connect" on ios or android, it is were I start usually, it would list any compliant advertising device, then it's possible to select it and discover whatever services it expose. Of course no guarantee that the datas can be used easily.

If it's possible to see a pattern, i.e. selected gear, battery level, maybe cadence, per example on garmin it's possible to develop a widget to show the infos on the watch or computer. Not as good as making a new type of sensor profile, but good enough for me.

The can bus, if it's really can bus and standard, there is shields for raspberry and others, or car sniffers, that may work for discovery. But then to use it, I don't know, it need his own hardware, not small, and consuming battery, would be better if bluetooth work i think.

Axs, di2, smart.shifting, they should expose at least a read only protocol instead of beeing closed systems. Mostly when they don't even propose their own solution ( no smart.shift gear display
available for a non ebike bike outside of a smart phone app ).

If you have the time to try ble discovery that would be great, otherwise maybe i go and buy that smart.shift bike I am interested in and try but i am not sure yet.

[timangus]

So I had a little poke. The good news is that it does advertise, it does connect and the current gear is available as a Service Characteristic. The first byte of 00000001-33d2-4f94-9ee4-9312b3660005 is definitely the value in question. I don't know what the other byte is, I thought maybe battery level encoded in some way, but it doesn't seem to be dropping or indeed changing at all, so I don't know. There are a bunch of other Characteristics; one of them is definitely the gearbox serial number, and there is one that is writable that is presumably the means by which the app changes settings. There is also a separate Service that has the cadence and speed sensor values.

The bad news is that the system only advertises for a small time when it first starts up (100 seconds I think) or if you put it in "pairing mode" by holding the rear shift button for a few seconds. (You can see why really as there is no authentication involved at all, so if it were advertising all the time, the system would be permanently open to attacks.) Calling it pairing mode is a misnomer really since, as far as I can tell, it doesn't support pairing/bonding. In order to get the data into a Garmin app therefore, you would need for it to connect during the initial advertising period, or do so manually, and hope that it stays connected for the duration of your ride. If the connection did drop, as far as I understand (having given myself a crash course in BLE) it won't automatically reestablish itself; I don't think it does ADV_DIRECT_IND as far as I can tell, but I haven't tested it thoroughly. So there is the possibility that if the connection isn't reliable, it would need for the user to turn advertising on manually from time to time, at the very least.

Anyway this is all quite interesting. I confess it hadn't occurred to me that it would be possible to make a Garmin app to connect with it -- seems like something Pinion should be doing themselves. With a bit of packet sniffing I'm fairly sure it would be possible to effectively clone the phone app into a Garmin app and in that way it would solve my frustrations with not being able to change settings like Pre.Select on-the-fly. I might have to have a closer look at this 🤔.

(And it's definitely CAN bus physically in the loom, by the way. I've had a scope on it and just visually it looks correct, but there is a setting in the app to turn CAN bus on and off, so there is no doubt. It seems a lot of eBike systems use it to drive the various components, displays, buttons etc....)

[spatcho]

hey, thanks, very cool to see that

the advertising is only shortly after startup : how does the app work ? it can connect any time or need to do it at startup or need you to hold the rear shift button ?

[timangus]

Yeah, at startup or after holding the button, i.e. only when it's advertising. It's actually quite poorly named/documented. It lists "Paired Devices" implying some kind of conventional permanent bonding, but really it's more of a "bookmark". I'd mentioned in one of my blog posts that it doesn't connect reliably, in reality it's just that it can't connect, unless the Smart.Shift happens to be in advertising mode; this isn't made clear at all in the app or documentation.

[timangus]

[spatcho]

Well done ! But if BLE connection is not reliable it is a dead end. Can bus may work, I see it is quite used among ebikes (I knew it only from cars), maybe a non motorized smart shift pinion would connect to a pinion ebike display, of course not display battery info and other ebike specifics, but allow smart shift setup and gear display. For Garmin and other sport watches and computers, this could be used to make a can to ble bridge : https://www.tindie.com/products/fusion/can32-an-esp32-dev-board-with-can-bus-v21/ . I think I will wait to see what pinion will do for 2026 before buying a bike with pinion smart shift.

[spatcho]

Bought two of those can - ble bridges (https://www.tindie.com/products/fusion/can32-an-esp32-dev-board-with-can-bus-v21/), will try them on the can devices I have and let you know

[pschlan]

Nice to find this... I made a datafield for Garmin to show gear and battery status. I did some re-engineering and have access to pretty much all of the data by now.

https://imgur.com/a/zJzJ5E0

But I didn't publish it yet because the BLE connection seems to drop after a few minutes of riding. Did you experience the same issue? It's a bit puzzling since it seems there are BLE based cycling computers form Sigma which can connect to the SmartShift box via BLE, and I'd expect that they have a stable connection. I didn't try any of those myself, though.

By the way, I also wired Shimano shifters to the system (https://patsch.dev/2024/11/14/pinion-smartshift-with-a-shimano-grx-di2-lever/) and currently looking into building a USB-C adapter for charging the battery. (Power bank would be much nicer than using that Pinion/Ansmann PSU.)

[timangus]

@spatcho yeah Pinion don't seem to advertise the compatibility of the various FIT eBike displays being compatible with Smart.Shift, but there are OEM bikes (e.g. Stromer ST7) that have hardware displays; they must connect with CAN. Those boards you linked look ideal for prototyping what I had in mind (though from the reviews it sounds like they're poorly documented). Will be interesting to hear how you get on. To reverse engineer the data itself, it might be necessary to get one of the displays, assuming it can be made to work at all. They're quite expensive 😬.

@pschlan ah you have taken this much further than I have. My gear display data field is the absolute bare minimum hacked together scan->connect->disconnect->scan loop type thing. I just wanted to see how reliable it is before I spent too much time on it. And, as you have found out too, it is not very reliable. It seems to lose connection every 10 minutes or so, mandating "pairing" mode to get it working again, so it's not really practical. I think without being able to properly bond the devices, this is a dead end. I may still persevere with making a widget to turn Pre.Select on and off, that's my main use case, I'm not actually that bothered about displaying my current gear. To that end I've also reverse engineered the protocol, eventually I wrote a dissector for Wireshark. I'll upload it somewhere if you're interested. There are still some messages I don't understand, but the ones that I do are enough for my purposes.

I haven't actually seen one of these Sigma computers demonstrated, indeed I've only ever seen it described as a potential option. Do you know for sure that they actually work with Smart.Shift? Perhaps there is some special handshake to enable bonding?

Good job with the shifters, shame about the TRP ones. Interesting that you mention making a USB-C adapter; someone else emailed me about doing that (asking about pinouts on the wiring loom) a few weeks back, I replied but didn't hear anything further. At first I assumed you were the same person, but you have a completely different name!

[pschlan]

@timangus I don't know for sure, and for > 100 EUR, I didn't want to try... Maybe one day I will try.

Regarding the CAN, the SmartShift's BLE GATT service exposes characteristics which allow you to send CANopen requests and receive responses. The official app seems to use this channel as well to perform certain operations. This could be an option to play with CAN traffic without having to hook up a CAN<->BLE adapter. Of course, later on a dedicated board would be good for stability.

Multiple people working on USB-C charging solutions shows me that Pinion really missed an opportunity here. So far, I think a simple 2S charger like https://www.amazon.de/dp/B0CJY3ZMNH should work - I ordered one, but was not brave enough to try yet. Wanted to capture current and voltage over time during charging when using the official adapter first to be sure I'll not damage anything.

Do you know if the pins of the charging port are directly connected to the battery pack, or is the connection looped through the SmartShift box first?

[timangus]

Regarding the CAN, the SmartShift's BLE GATT service exposes characteristics which allow you to send CANopen requests and receive responses. The official app seems to use this channel as well to perform certain operations. This could be an option to play with CAN traffic without having to hook up a CAN<->BLE adapter. Of course, later on a dedicated board would be good for stability.

Oh really, I hadn't noticed anything of that nature. Which operations elicit that response, and on which characteristic? In the form of a Wireshark dissector, here's where I got to in terms of reverse engineering the protocol, for what it's worth:

Wireshark Smart.Shift BLE dissector

smart_shift_proto = Proto("smart.shift", "Smart.Shift Post-Dissector")
local smart_shift_type_field = ProtoField.string("smart.shift.type", "Type", base.ASCII)
local smart_shift_property_field = ProtoField.string("smart.shift.property", "Property", base.ASCII)
smart_shift_proto.fields = {smart_shift_type_field, smart_shift_property_field}

local btatt_value_f = Field.new("btatt.value")

local READ_TYPE  = 0x01
local REPLY_TYPE = 0x02
local WRITE_TYPE = 0x03
local ACK_TYPE   = 0x04
local UNK1_TYPE  = 0x05
local UNK2_TYPE  = 0x06

local type_tbl =
{
    [READ_TYPE]  = "Read",
    [REPLY_TYPE] = "Reply",
    [WRITE_TYPE] = "Write",
    [ACK_TYPE]   = "Ack",
    [UNK1_TYPE]  = "Unk1", -- Something to do with fault codes
    [UNK2_TYPE]  = "Unk2", -- ""
}

function default(values)
    if #values == 1 then
        return values[1]
    end

    return string.format("[%s]", table.concat(values, ", "))
end

function dotted_quad(values)
    return table.concat(values, ".")
end

function boolean(values)
    if values[1] == 0 then
        return "[OFF]"
    end

    return "[ON]"
end

function power_supply(values)
    if values[1] == 1 then
        return "[Pinion Battery (P6510)]"
    elseif values[1] == 3 then
        return "[Direct connection to 12V e-bike battery]"
    elseif values[1] == 4 then
        return "[DC/DC converter P5620]"
    end

    return "[Unknown Value]"
end

function speed_sensor(values)
    if values[1] == 0 then
        return "[No speed sensor]"
    elseif values[1] == 1 then
        return "[Pinion speed sensor (P8360)]"
    elseif values[1] == 3 then
        return "[CAN message]"
    end

    return "[Unknown Value]"
end

function trigger_mapping(values)
    if values[1] == 1 then
        return "[Normal]"
    elseif values[1] == 2 then
        return "[Reversed]"
    end

    return "[Unknown Value]"
end

function settings_write(values)
    if values[1] == 0x56a93c03 then
        return "[ENABLED]"
    elseif values[1] == 0 then
        return "[DISABLED]"
    end

    return "[Unknown Value]"
end

function battery_level(values)
    return string.format("%.2f%%", values[1] / 100.0)
end

local property_tbl =
{
    [0x091000] = {name="Hardware Version",          unit=1, f=dotted_quad   },
    [0x561f01] = {name="Firmware Version",          unit=1, f=dotted_quad   },
    [0x561f02] = {name="Bootloader Version",        unit=1, f=dotted_quad   },
    [0x181004] = {name="Serial Number"                                      },

    [0x252500] = {name="Mounting Angle"                                     },
    [0x023402] = {name="Rear Teeth"                                         },
    [0x023403] = {name="Front Teeth"                                        },
    [0x023401] = {name="Wheel Circumference"                                },
    [0x003402] = {name="Power Supply",              f=power_supply          },
    [0x003405] = {name="CAN bus",                   f=boolean               },
    [0x003404] = {name="Display",                   f=boolean               },
    [0x003401] = {name="Speed Sensor Type",         f=speed_sensor          },
    [0x003001] = {name="Number of Magnets"                                  },
              
    [0x502500] = {name="Reverse Trigger Mapping",   f=trigger_mapping       },

    [0x016102] = {name="Current Gear"                                       },
    [0x646101] = {name="Battery Level",             f=battery_level         },

    [0x122502] = {name="Auto Start Gear"                                    },
    [0x112500] = {name="Pre.Select Cadence"                                 },
    [0x122501] = {name="Start.Select",              f=boolean               },
    [0x132500] = {name="Pre.Select",                f=boolean               },
    
    [0x003004] = {name="Settings",                  f=settings_write        },
    [0x002500] = {name="Number of Gears?"                                   },
}

function hex_string_for(bytes)
    return "0x" .. string.lower(bytes:bytes():tohex())
end

function filter_string_for(s)
    return s:gsub("[^a-zA-Z]", "_"):lower()
end

function smart_shift_proto.dissector(buffer, pinfo, tree)
    local att_value = btatt_value_f()
    if not att_value then
        return
    end

    local all_bytes = att_value.range:bytes():tvb("Smart.Shift")

    local type = all_bytes:range(0, 1):uint()
    local type_string = type_tbl[type]
    if not type_string then
        return
    end

    local subtree = tree:add(smart_shift_proto, buffer(), "Smart.Shift")
    
    subtree:add(buffer(), "Type: " .. type_string .. " (" .. type .. ")")
    subtree:add(smart_shift_type_field, filter_string_for(type_string)):set_hidden()
    pinfo.cols.info = string.format("Smart.Shift %-5s", type_string)
    
    local number_payload_bytes  = all_bytes:range(1, 1):uint()
    local property_bytes        = all_bytes:range(2, 3)
    local property_bytes_hex    = hex_string_for(property_bytes)

    local property_string           = ""
    local property_string_verbose   = ""
    local property_string_filter    = ""
    local property = property_tbl[property_bytes:uint()]
    if property then
        property_string = property.name
        property_string_verbose = property_string .. " (" .. property_bytes_hex .. ")"
        property_string_filter = filter_string_for(property_string)
    else
        property_string = "Unknown (" .. property_bytes_hex .. ")"
        property_string_verbose = property_string
        property_string_filter = "unknown"
    end

    subtree:add(buffer(), "Property: " .. property_string_verbose)
    subtree:add(smart_shift_property_field, property_string_filter):set_hidden()
    pinfo.cols.info:append(" " .. property_string)
    
    if type ~= REPLY_TYPE and type ~= WRITE_TYPE and type ~= UNK2_TYPE then
        return
    end

    local value_bytes           = all_bytes:range(5, number_payload_bytes)
    local value_bytes_hex       = hex_string_for(value_bytes)
    local value_string          = "";
    local value_string_verbose  = "";

    if property then
        local values = {}

        local unit = number_payload_bytes
        if property.unit then
            unit = property.unit
        end

        local n = number_payload_bytes / unit
        for i = 0, n - 1 do
            values[#values+1] = value_bytes:range(number_payload_bytes - ((i + 1) * unit),
                unit):le_uint()
        end

        if property.f then
            value_string = property.f(values)
        else
            value_string = default(values)
        end

        value_string_verbose = value_string .. " (" ..
            hex_string_for(all_bytes:range(5, number_payload_bytes)) .. ")"
    else
        value_string = value_bytes_hex;
        value_string_verbose = value_bytes_hex;
    end

    subtree:add(buffer(), "Value: " .. value_string_verbose)
    pinfo.cols.info:append(" " .. value_string)
end

register_postdissector(smart_shift_proto)

Multiple people working on USB-C charging solutions shows me that Pinion really missed an opportunity here. So far, I think a simple 2S charger like https://www.amazon.de/dp/B0CJY3ZMNH should work - I ordered one, but was not brave enough to try yet. Wanted to capture current and voltage over time during charging when using the official adapter first to be sure I'll not damage anything.

That seems like it would work, but I know very little about battery charging technology I'm afraid. It seems like the system is quite flexible in how it derives power though, so you would hope that this implies it is well protected, electrically.

Do you know if the pins of the charging port are directly connected to the battery pack, or is the connection looped through the SmartShift box first?

Here's a diagram I drew of the loom soon after I got it. Please don't take it as definitive, I haven't even written the gender of the connectors on it so the pins may be mirrored in practice (🤦). Sorry, it was months ago. But the answer to your question is that it's directly connected to the battery and the Smart.Shift box. Unless it's not obvious, the left most purple connector is for the battery, the black is the Smart.Shift box, the green is what the charge cable (with the other purple connector) attaches to, the blue the shifter cable, and finally the yellow is for the speed sensor.