Problem:
We are using Inline 7 in combination with the NVH kit to get our vehicle speed and engine speed.
But engine speed in this case is the Internal combustion engine and not the elektro motor.
Question:
We want all tree variabels in an ideal world but would be happy if we could ditch ICE speed for Elektro motor speed.
Type vehicle:
VDL bus (Public transport) with a serie hybrid setup. ISB4.5 Cummins motor powering a Siemens generator and a Siemens PEM elektromotor powering the wheels via an AV132 Axle of ZF
Research done so far:
The message with the needed info is:0x0CF00203 SPN 161. Screenshot in attachment.
But as stated below copied from this website https://canlogger.csselectronics.com/ca ... quest-data the format is different. I get lost in the ISO documentation where exactly i can find the official request message.
To send a J1939 request via the CAN bus, a special 'request message' is used (PGN 59904), which is the only J1939
message with only 3 bytes of data. It has priority 6, a variable transmit rate and can either be sent as a global or specific
address request. The data bytes 1-3 should contain the requested PGN (Intel byte order). Examples of requested J1939
messages include the diagnostic messages (e.g. J1939 DM2).
And extra issue is that I can't translate it in the 1 byte PID that is used in the PID library, see screenshot.
NVH for EVs is something we continue to work with and EVs in heavy duty using J1939 is on our radar.
As development continues it maybe we need some support with various vehicles and if required we would approach Pico users to see if they would be able to help.
Fingers crossed it won't be much longer before we have something so watch this space.
As Ben has mentioned the software teams are on the case with the acquisition of e-motor speed via the diagnostic system
In the interim, something you mentioned above "We want all tree variabels in an ideal world but would be happy if we could ditch ICE speed for Elektro motor speed.
This week a similar request came in from China and as a result, next week I will look at the feasibility of using the motor speed and position sensor or, motor phase current as a speed input on channel D for NVH
I am not sure if this will work but "nothing ventured nothing gained "
They are still missing, can you send them to support@picotech.com and we can add them for you
done, thank you Martyn. Don't know what I'm doing wrong here.
This week a similar request came in from China and as a result, next week I will look at the feasibility of using the motor speed and position sensor or, motor phase current as a speed input on channel D for NVH
I tried picking the signal from the position sensor, is an encoder signal with 15V supply, Square wave, I've added a waveform in the picolibrary under brand VDL, see screenshot in attachment. I couldn't add a filter to channel D making the signal unusable in real life testing, If I could add a low band pass filter this would patch my problem here.
But Canbus data is known so I hope you, Ben and the SW team can find a easy way to add specific canbus messages. My advantage here is that we know whats on our CAN bus. but for UDS stuff we rely on diagnostic software of our suppliers. So I send a request to Siemens and Cummins if this message is supported via UDS.
Sidequest:
don't want to hijack my own thread here but still not able to view my own waveforms via picoscope 7 7.1.13.17046 see 2nd screenshot (In Dutch).
Following on from the above suggestion of graphing e-motor speed instead of engine rpm in our NVH signal history, please see the information below:
Having knowledge of the e-motor construction is paramount and so using our Mk VII e-Golf (which has been reverse engineered here topic22767.html) we can see our rotor speed and position sensor generates 5 electrical cycles per rotation of the rotor
1
Using the NVH “RPM Signal” option “Channel D Square wave/Tach” we connect channel D (via a x1 test lead) to the e-motor speed and position sensor (G713) signal (See configuration below)
2
Using the above RPM Signal option and populating the Advanced Vehicle Settings dialog with the total gear ratio (9.756:1) we can also obtain road speed (See configuration below)
3
With gear 1 selected, the vehicle was driven and the graphing of e-motor and road speed was achieved. However, note the spikes present on the RPM/Road speed signal due to electrical noise present on the G713 signal. These spikes occurred with the vehicle stationary in “Drive”
TA167 is required as it can handle the typical e-motor current (10 mV/A in 200 A mode) and can be connected without “probe detection” by the NVH software if using a PicoScope 4425A. The NVH software does not permit the use of the BNC+ 2000 A clamp to Channel D at this stage
5
Above we can see how progressive acceleration (approx. 50 seconds into the signal history) returns sensible e-motor and road speed values (approx. 10,000 rpm @ 75 mph). However, under other driving conditions the phase current is subjected to electrical noise, resulting in either spikes or crazy e-motor rpm values (> 20,000 rpm)
To view the noise present when using either the current clamp around an e-motor phase or a x1 test lead connected to the rotor speed and position sensor signal, we have used PicoScope
6
Note above the electrical noise present within phase “U” during over-run (freewheeling) along with the dramatic rise in current during braking regeneration and selected regeneration using phase shift
Below we have added a frequency math channel to highlight the effects on the graphed e-motor speed during the various driving transitions above
7
Applying a 10 kHz low pass filter improves the graphed e-motor speed dramatically but does not fully cure! (at present we cannot filter the RPM input into channel D of NVH)
8
Below we have the noise level captured with the vehicle in “Drive” but stationary; when selecting “Park”, the noise level diminishes considerably. (Hence the spikes present in the signal history when motor speed and position sensor and potentially phase current are used for graphing e motor RPM)
Phase current
G713 Signal
To conclude at this stage:
• Where possible, use an e-motor speed and position sensor signal as your “Square wave/Tach RPM” input (knowledge of rotor pole count will be required)
• Using phase current is possible but challenging due to electrical noise during driving transitions
NVH software recommendations:
• NVH to permit connection of BNC+ 2000 A clamp to channel D
• Filtering to be permitted when channel D used for “Square wave/Tach RPM” input
I hope this helps and rest assured the software team are working on a solution via CAN