[k90]

Hello Gurus,

As you might know I have started to decode BSD bus in another thread to gain information about alternator load.
EDIT: https://www.e90post.com/forums/showthread.php?t=1966355

After days of sleep deprivation caused by manic sweaty coding(non-automotive), sampling signals from the car and polishing the corners I'm at point I cannot get easy gains anymore. Next I would likelly need to probe into device internals and do otherwise mechanically intrusive things to gain more information. Making a breakout version of alternator regulator is not out of option. I need to check the price for the regulator.


Cut to the chase

I wanted to review the decoder here and maybe hopefully get some samples from the field to improve annotations in the decoder before eventually submitting and forgetting it to sigrok project.

These kinds of samples(200kHz min. 500kHz recommended. EDIT: in a pinch lower than 200kHz will suffice) are sought after:

• Car has IBS. For the bus address OR
• Car has 400W coolant pump. To see the differences if any to 200W OR
• Diesel? Alternator differences?

Virtually any logic analyzator file format is fine.
I'll just write another decoder if it's not supported by pulseview/sigrok.
https://sigrok.org/wiki/Input_output_formats
Or captures can be done directly using Pulseview
https://sigrok.org/wiki/Supported_hardware

In IBS car I would maybe probe the signal from the battery sensor as it's clean and dry area.
Note the signal is +12v level.


The Decoder

If you want to try out the decoder it's in the attachments and has instructions inside.
There are captures from my car in the other .zip files.
Device and register names are in pd.py a variable named _BSD_DEVICES.

Software:
https://sigrok.org/wiki/Downloads here is Pulseview(Release build)
https://github.com/knarfS/sigrok-bui...tag/continuous found also working nightly build repo


About the review version of the decoder:

• Known flaw: Engine and bus states that reach end of file are not annotated(in windows release and nightly versions, not in linux nightly build)
• Known flaw: Engine state running detection is not nailed down and needs more frame match logic to make the assumption better
• Annotation names for devices and registers need footwork

[DuaneM]

Hi there, you have done great work on this problem. I have done a lot of reversing on car comms busses and the BSD is one I could never make sense of.
I have downloaded your files and will give them a shot.

I have an e92 325i which uses BSD coolant pump, alternator etc as does your example.

There are many people who buy replacement Pierburg coolant pumps for racing applications which can never get them to run (if they buy the e90 parts), they assume it's PWM like other Pierburg pumps.

So your work here matches perfectly some stuff I tried about 5 years ago with no success, to decode these signals.

Should be easy to build a Teensy 4.0 device to run the coolant pumps or alternators based on your work !

Many thanks for your posts, hope to see more if you make more progress.

[JonOhh]

Originally Posted by DuaneM

Hi there, you have done great work on this problem. I have done a lot of reversing on car comms busses and the BSD is one I could never make sense of.
I have downloaded your files and will give them a shot.

I have an e92 325i which uses BSD coolant pump, alternator etc as does your example.

There are many people who buy replacement Pierburg coolant pumps for racing applications which can never get them to run (if they buy the e90 parts), they assume it's PWM like other Pierburg pumps.

So your work here matches perfectly some stuff I tried about 5 years ago with no success, to decode these signals.

Should be easy to build a Teensy 4.0 device to run the coolant pumps or alternators based on your work !

Many thanks for your posts, hope to see more if you make more progress.

So just to add to this, the BSD enabled pierburg pumps will indeed run fine controlled by PWM, depending on if pin 2 is pulled high and BSD comms established on pin 3, or if pin 3 is pulled low, enabling pwm control over pin 2.

Something to note though, is that they made a revision to the pump controller at some point and in doing so there was a slight behavior change in case of communication faults.

Regardless, knowing the BSD communication allows far greater functionality of the pump and is definitely still interesting!

[k90]

Originally Posted by DuaneM

Should be easy to build a Teensy 4.0 device to run the coolant pumps or alternators based on your work !

That python script was kinda easy even without knowing how to python really. More sweat about the protocol itself. And no TX.

UPDATE

I'm questioning my choises but now finish line really looks like it's getting closer.

I have written portable transceiver(yes tx features too as a build option) library in C(ANSI C11) that should run on virtually any microcontroller with one timer for the task. 8bit timer, 16bit timer, anything.
It's written especially 8bit mcus and strict ram use in mind.

Recommended to have at least capture interrupt for RX and compare match output if TX.
Compared to LIN this bus protocol has way lower hardware requirements as LIN requires UART/USART of some sort to be implemented in clean way leaving the cheapest, smallest 8bit MCUs on the table.

Library itself is master/slave agnostic, but interrupts provided by separate header have master/slave operating mode build time option for instances to provide sync.

More:

• Fully static.
  
• Instances. Ie. one device can be slave for one bus and master for another allowing emulating things like 2 water pumps appearing as one, fake alternator etc.
  
• Fully automatic buffer management.
  
• Full frame error processing and flags for delayed processing and tx collision.
  
• Bus state monitoring for ie. master to detect short to GND or +V.
  
• Library functions have extensive unit tests.

Made serial formatter(receive only) example application as locally hosted. Picture attachment
It's using exported samples from the n52 engine start logic analyzer capture so the data is the same than in the logic analyzer view.

Proceeding to write build option for the example application for atmega328p(arduino) as it's lowest denominator I have available for serial output to see if it keeps up while outputting formated data.
After that it's time to write water pump test application for atmega328p to test tx+master. I have also yet to write application for controlling the cabin heater too.
Then see the damage (weight of the artifact ,function stack usage, stack waterline, cycle counts etc).
I kinda want to run profiling in QEMU for atmega and attiny to really see what is up.

Just for announcement for you to know I have this kind of code / knowledge available.
Not intending to open source or make this publicly available at least in full feature set.
But if you really really need the code or some sort of application written for the library code you can try to reason with me in DM's to make it for you.