Using intermediate IC's for pulse counting and ultrasound

So the project I'm working on is an Autonomous Trailer Hitching Robot, where we plan to use many many many forms of sensors (IMU, GPS, Ultrasound, Current Sensors, etc etc etc) to take a trailer over to a hitch ball and set it upon it with the push of a button. With that being said, we are using two arduino megas communicating over serial with each other (one as a movement brain and one as advanced sensory). Obviously I am concerned about timing requirements for each sensor to transmit it's data to the micro and to not be held up waiting for counting or timing.

So...for counting the pulses off of our motor encoders I recently found the 74HC4020 which can do the counting and transpose the number to binary (the amount of pins used in this situation is of no issue) so that saves the micro from being either interrupted or waiting for pulses... My question is does something exist to do the same kind of intermediate processing for an ultrasound sensor with a trigger and echo pin....perhaps something that can measure a time delay between two inputs? The sensor is an HC-SR04 btw...

Basically I want to convert any sensor that could cause a timing issue to some form of digital or analog input that can be read in the downtime between other crucial steps (such as user input from our controller in manual mode or other data) without sacrificing much sample time.

Also on an unrelated topic, is there a way to offset serial data on the mega so that two serial data streams are not competing for processing time? Ex. GPS data and Arduino communication. I'm just not sure how the mega handles it's different channels of serial data.

Sorry for the long post....

On second thought perhaps I misunderstood what the 74HC4020 was....I need an IC that will hold the count on it until reset not divide it, any recommendations?

matt99199: So the project I'm working on is an Autonomous Trailer Hitching Robot, where we plan to use many many many forms of sensors (IMU, GPS, Ultrasound, Current Sensors, etc etc etc) to take a trailer over to a hitch ball and set it upon it with the push of a button. With that being said, we are using two arduino megas communicating over serial with each other (one as a movement brain and one as advanced sensory). Obviously I am concerned about timing requirements for each sensor to transmit it's data to the micro and to not be held up waiting for counting or timing.

So...for counting the pulses off of our motor encoders I recently found the 74HC4020 which can do the counting and transpose the number to binary (the amount of pins used in this situation is of no issue) so that saves the micro from being either interrupted or waiting for pulses... My question is does something exist to do the same kind of intermediate processing for an ultrasound sensor with a trigger and echo pin....perhaps something that can measure a time delay between two inputs? The sensor is an HC-SR04 btw...

Basically I want to convert any sensor that could cause a timing issue to some form of digital or analog input that can be read in the downtime between other crucial steps (such as user input from our controller in manual mode or other data) without sacrificing much sample time.

Dedicated logic could do what you want. Most would implement it either a PLD or CPLD. Bare decade counters and octal latches could be configured to accomplish what you want. But you need to formalize the design requirement before you build it. Software is easily mutable, hardware is fixed.

Depending on the complexity of your sensors you could use Arduino Chips as I2C slave device. Each slave would control a sensor, or a group of sensors. They would have the control logic to do their simple task only. Complex integration would be handled by a Master processor.

matt99199: Also on an unrelated topic, is there a way to offset serial data on the mega so that two serial data streams are not competing for processing time? Ex. GPS data and Arduino communication. I'm just not sure how the mega handles it's different channels of serial data.

The serial processing on Arduino's are interrupt driven. Each byte in causes an interrupt to service that received byte. The 'new' byte is added to the end of the received data buffer, and the buffer pointer is incremented if possible. If the buffer is full, it overwrite the last byte received.

Outgoing data is processed the same way. The UART hardware has a two byte output pipe, the the TX buffer is a single byte register that holds the 'next' byte to be send. The Shift register holds the current byte being send. It sends each bit out it's shift register, when the last of the data bits have been send it transfer the 'next' byte from the UDR TX register to the shift register, issues a UDRE interrupt(which the Arduino HardwareSerial object answers by moving data from its 64byte output buffer to the UDR register). if the UDR register was empty it will issue a TXC (transmission complete interrupt) when the last bit + parity + stop bits has been shifted out.

The Mega has four hardware Serial UARTS, if you had all four of them sending and receiving at 115,200 baud, they are only moving 2X4 bytes 11,500 times a second or less than 100k bytes a second. The Mega runs at 16mhz, and can actually execute one instruction most clock cycles so you can execute over 160 instructions per character moved. You will have to do some cycle counting to see exactly howmany cycles are required to service each interrupt, I expect somewhere between 10 and 50. With these rough guesses, supporting the serial streams takes between 1/3 and 1/16 of the total performance of the processor. How much data are you moving per second? You should not be receiving 11kps from a GPS sensor?

If 16mhz Mega's are not fast enough, look at the SAM D20E 32bit (48mhz, 128k pgm, 16k ram). They are less than $4 in single qty, $1.75 @2000.

Chuck.

IMO you expect too much from external logic. The data transfer from those external chips may cost more time than they save in processing of the signals. It may be easier to use more controllers for dealing with I/O processing, where a controller can e.g. handle both the control of a motor and the related encoder signals. User interaction instead is a typical background job.

matt99199: On second thought perhaps I misunderstood what the 74HC4020 was....I need an IC that will hold the count on it until reset not divide it, any recommendations?

Stack two IC's a counter and a Latch

CD4040 -> 2 hct165

CD4040 is a 12bit counter, it counts the negative edge on its CP pin. If you connect is Qn outputs to the Dn inputs of the HCT165 (an 8bit parallel in Serial out Shift Register) you can capture the Qn values by pulsing it's PL input.

Just wire up the circuit. you need:

  • !reset, initialize the counter to zero (MR on the 4040)
  • some clock signal that is counted each time it goes from High to Low (CP on 4040)
  • !latch to store the current count of the 4040, (PL on the HCT165)
  • shift in, the input from this circuit to the Arduino.
  • shiftClock, a clock output from the Arduino to clock out each bit of the parallel to Serial converters (HCT165)
  • !CE, the enable pin on the HCT165 to start the serial out flow

You can do the same thing with parallel latches AHC573 8bit parallel Latches, but, you would need 8pins to input each byte, and another pin for the output enable.

Chuck.

Have a look on the US-100 Ultrasonic sensor. It’s very similar to the HC-SR04 but has a few advantages like:

  • Run from 3.3V
  • Has a Standard and Serial Interface (UART)
  • Has built-in temperature sensor and uses it for compensation

Basically you can send a byte via Serial (Software serial for example) and read back the distance, all already calculated and temperature compensated. You also can read the temperature only with necessary.

The sensors has a similar price compared with SR04, but they’re not as popular - I don’t know why, as I think they are much better.

Hi,

So the project I'm working on is an Autonomous Trailer Hitching Robot, where we plan to use many many many forms of sensors (IMU, GPS, Ultrasound, Current Sensors, etc etc etc) to take a trailer over to a hitch ball and set it upon it with the push of a button.

Sorry but why many,many,many.. sensors. Have you drawn out a block diagram of all these sensors and what you need them for? GPS, I don't know, but how far away is the vehicle from the hitch. How are you going to detect the the hitch. How are you going to locate the hitch. How are you going to use the robot to move the vehicle. There are many varieties of sensors, cost, ease of use and performance.

Sorry but just piling sensors in without explanation of how you will use them, is not going to help any recommendations.

Tom.... :)

Thank you all for the quick replies! I'm interested in these US-100 ultrasonic sensors now and have some on order to play around with, as for the encoders I believe chucktodd confirmed a solid plan to tackle that. The GPS sensors are sending out updates at only 5Hz but I do have two of them in this setup and was hoping there was a way they would not overlap constantly on rare occasions, causing loss of data. Really these were my only concerns with this project considering these are the two time consuming processes, I didn't mean to get into a whole "this is my project and I have no idea what I'm doing" kind of situation so that's why I left out the main details of my project (it might be getting patented so I can't give too much away :P). Thanks again you guys!

My question is does something exist to do the same kind of intermediate processing for an ultrasound sensor with a trigger and echo pin....perhaps something that can measure a time delay between two inputs?

You can read the HC SR04 type ultrasound sensors with non blocking methods using pin interrupts or timer caputure interrupts. You will not use pulseIn().

Indeed the Arduino hardware timers in input capture mode will do exactly what you want--measure a time delay between inputs.