Yes and no. Yes, the transmitting of commands and data to the sensor could be done using a standard UART Tx. However, the return echo is not standard communications and would make no sense on a Rx pin of a UART. The echo return from the sensor is in raw pulses that must be timed by the master CPU.

When probing the Bosch ECU and sensors, while they were being tricked into thinking they we actually operating in a vehicle, I saw two different initialization sets. One set for the two outboard sensors and a different set for the middle two sensors. In my code, I simply initialized all four sensors with the same block of data. However, I included the unused senMidInit array for future use.

The two inboard sensors (or middle sensors) act very similar. Well, for that matter, the two outboard sensors act similar too. So, there is little reason to keep four sets of initialization patterns. As a retired supplier to GM, I know it’s hard enough to calibration two sets – four sets would just double the work.

Yes, the sensors in this demo are all from Bosch. Last I knew, there were three suppliers of ultrasonic systems to GM. In the old days (pre 2006) it was only Bosch. My company was second which got started back in 2006. Again, last I knew, all ultrasonic OEM supplies both the ECU and sensor as a calibrated set. Otherwise, there would be too much finger pointing when things go bad. Plus, each OEM holds their sensor intellectual property tight.

No, I have no way of knowing what the actual init bytes represent. And yes, it would be cool to know. My guess, the init bytes set gain values for different distances. So, the middle sensors probably have a hotter set of gain values compared to the corner sensors. All speculation on my part. But it would be easy to test out by trying different values and then testing the sensor’s ability to detect objects at different distances.

Good luck,
Jim

Some questions about the initialization string: I believe you said the init string appeared to be 9600 Baud serial data. Could it be simulated with a standard serial port, (Tx channel only)? In looking at the Logic Analyzer waveform it looks like it might be negative logic (i.e. low voltage is logic 1). If your Logic Analyzer thinks the signal is standard serial port stuff, does it provide details like number of data bits, parity, stop bits, etc?

You define a table for senMidInit[], but I don’t see it used anywhere in the code. Apparently this table is for initializing the middle sensors? Why do you suppose there are only 2 unique init strings instead of 4?

Are the sensor modules in this demo made by Bosch? Somewhere I think you said GM uses Bosch sensor modules. If so, does Bosch provide application data for their modules? Knowing the purpose of the various bytes in the initialization string might be very useful.

RichD

Very cool. You gotta send me your source code with finished. I’ll create another page dedicated to Arduino with your source attached.

The Mbed source code I posted pings four sensors. However, only the right sensor echos are measured. This is done by attaching an interrupt to the rising and falling edge on the Rx line coming from the right sensor. In the main loop, you can see the right sensor is pinged, then a 50ms loop runs to allow echos to come back. The interrupt routines senRxIrqRise and senRxIrqFall capture timestamps into an array. After 50ms in the main loop, any timestamps that have been captured are printed out.

The Mbed code above is not very good. Looks like there is a bug in senRxIrqFall one the line “tmrEchos[ indEchos++ ] = timer.read_us();”. This should have been (I think – it’s been a while) “tmrEchos[ indBuff ][ indEchos++ ] = timer.read_us();”

So, all four sensors are pinged but only the right sensor’s echos are captured and sent back to the PC through the serial port. The Mbed code was just an attempt to get the hardware up and running and to prove echos could be captured.

Good luck and send more feedback with questions and your successes. Would love to see pics of your Arduino talking to some sensors.

Hope this helps,
Jim

Best I can tell the Mbed is only exciting the sensor modules, measuring the time interval of the echo return is not included. Correct?

RichD

Wow, looks like you have done a lot of digging into floating point on the F4.

Here is a link to another forum that also has a lot of really good info about floating point + FreeRTOS:
http://sourceforge.net/projects/freertos/forums/forum/382005/topic/4761747

My source code was based on the work done by Thomas Kindler who is the moderator of the forum on SourceForge. He’s a good guy and very helpful. He was the guy who sorted out how to get FreeRTOS to perform preemptive task switches on the F4 Discovery board while using floating point. He appears to me to be a real expect on this stuff.

Jim