Anyone familiar with the communication used on E-bikes? AKA , NO. 2 COMMUNICATION PROTOCOL
I believe this is a form of I2c format. Any standards apply?

 

Is it a serial protocol? The information I see is a uart type data stream.
https://github.com/EBiCS/EBiCS_Firmware/blob/master/Src/display_No_2.c

I don't know about the specific types for ebikes so it's a guess searching for NO. 2 COMMUNICATION PROTOCOL

 

Yes, I already did the search route, just wondered if there was anyone had already dabbled in it.

 

My strong suspicion, and it is only a suspicion, that it would be some sort of CAN physical layer.

 

Yes, I already did the search route, just wondered if there was anyone had already dabbled in it.

The problem is from a quick search, is that you need to know the exact combo of controller and display as there of so many versions and types CAN, based, UART base, on and on.... The actual protocol looks very simple.

https://topeparts.com/what-ebike-protocol-is-for-lcd-display/

 

I damaged the display on my Ebike, an Lectric XP3
The replacement came with a small leaflet identifying the 4 wires, B+, B-, Data+, Data-
That data structure would lead me to think that it is a differential signaling layer, like a CAN variant.

 

I damaged the display on my Ebike, an Lectric XP3
The replacement came with a small leaflet identifying the 4 wires, B+, B-, Data+, Data-
That data structure would lead me to think that it is a differential signaling layer, like a CAN variant.

Sure, but as you know, there is no standard physical layer or differential signaling layer for these Ebikes. I would use CAN on a fresh design but old RS485 would work if that was the hardware given to the embedded software guys.

To know for sure, you need the exact hardware devices and interconnects.

 

I would also choose CAN

 

I may choose a add on unit that is non-invasive, i.e. a stand alone/self contained add-on.

 

That format sounds a bit like USB. That might possibly be worth investigating. Of course, USB is a hardware spec, so it might take a lot of digging.

 

RS422/RS485 wouldn't require licensing costs, but CAN would (or at least used to!) Attach a scope and see

 

RS422/RS485 wouldn't require licensing costs,

How so??
I implement it all the time?

 

Helpful?
https://topeparts.com/what-ebike-protocol-is-for-lcd-display/

 

Helpful?
https://topeparts.com/what-ebike-protocol-is-for-lcd-display/

That's good but already posted in #5

 

How so??
I implement it all the time?

You DO NOT need to pay any licensing fees to use RS422/485.

But I have a feeling that a licence needs to be paid for if you are using CAN (although some chips that have embedded CAN may already pay for this on your behalf). See https://electronics.stackexchange.com/questions/285611/can-bus-licensing

For personal projects, it's very unlikely if you were to be found out, but commercial and open source would be more easily discovered.

If I were to create a new device, I would be looking at free protocols over commercial ones - unless there was a distinct need for it.

 

You DO NOT need to pay any licensing fees to use RS422/485.

But I have a feeling that a licence needs to be paid for if you are using CAN (although some chips that have embedded CAN may already pay for this on your behalf). See https://electronics.stackexchange.com/questions/285611/can-bus-licensing

For personal projects, it's very unlikely if you were to be found out, but commercial and open source would be more easily discovered.

If I were to create a new device, I would be looking at free protocols over commercial ones - unless there was a distinct need for it.

It just one of many IP costs in the chip biz. The CAN cost for implementation is a nothing burger in the total costs.

 

It seems to me that the main reason for using digital communications is to keep it proprietary so that all the hardware will only be available from one source.