TTL, voltage, one-wire test rig

[adamaero]

Spec​

My job, as an undergraduate EE student, is to create a test rig for offsite electronics (environmental sensors hooked up to a data logger, 12V batteries and solar panels). The test rig should be able to evaluate output from sensors (serial TTL, analog voltage, 1-wire) and output required signals (TTL, voltage, pulse, 1-wire) that could be supplied to the data logger to test wiring connections, logger analog inputs, relays, etc.

For example, we are getting incorrect data from an ultrasonic sensor (MB7380) operating on TTL. I do not know if the sensor is outputting the correct signal, or if the logger is not reading the sensor correctly. The test rig should eliminate this problem, and help with QA/QC during fabrication.
____________________

Attempt​

At first I thought about using a DSO203 Pocket-Sized Oscilloscope which can also output 10Hz to 8MHz. (Datasheet here.) Although, I do not think that could evaluate the 1-wire thermometer--and it seems my adviser (not an EE) wants something more user friendly to the average Joe. I mean, it seems that I am supposed to create another PCB board with various probes and green and red LED pairs for good or bad (for each type of sensor).

What do you think? What would you do? My adviser has not given me any other requirements.
____________________

Extra​

Overview of 1-Wire Technology and Its Use

 

[berkeman]

The DSO or other data acq equipment may be useful for part of this, but I'd think that using an Arduino or other microcontroller (uC) to do much of the communication testing might work well. Do you have access to such uC development boards? If so, which ones?

And could you show us a block diagram? It would also help a lot to know which communication paths are 1-way and which are bidirectional. The bandwidths of the signal, the wire lengths, the types of wires (controlled impedance Zo = ?), etc. will also help.

Also, are you already familiar with the various termination schemes for transmitting data/information over communication cables?

 

[adamaero]

Digital Storage Oscilloscope? So you're saying that buying the handheld oscilloscope is a good idea?
I do not have access to uC dev board. I also do not know what that is.

My emphasis is not computers. I know every little about protocols (for the one-wire sensor).

 

[adamaero]

The GPIO pins were chosen out of house. An electrician, in house, who wired the rest of data logger board (flexs Q4) just wired the GPIO pins it how they told him. And now they tasked me, an EE student, with the project of creating a test rig.

The pins that are connected use the following:

• UART_RX/PC Console RX
• GPIO3
• GPIO5/UART2_RX/SPI_IN
• GPIO6/SPI_SCK

(Excluding the power and ground pins.)

 

[adamaero]

This question/discussion was moved to the homework section. Although, it is a technical project I need some direction on.

What about using CY8CKIT-050? It is $93 on https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8CKIT-050B/428-3184-ND/3770081, and the IDE is free. I have not done anything with embedded systems, but it seems to be what I need to implement to test the GPIO...

 

[adamaero]

Excluding the 1-wire, is the quickest solution the https://www.amazon.com/dp/B006J4FZMO/?tag=pfamazon01-20? which can also output 10Hz to 8MHz digital signal.

 

[berkeman]

It would still help a lot to see the block diagram of the system, and if you could answer the questions in Post #2, that would also help. Thanks.

 

[adamaero]

https://flexscada.com/manuals/flexsq4/
The pins that are connected use the following:

• UART_RX/PC Console RX
• GPIO3
• GPIO5/UART2_RX/SPI_IN
• GPIO6/SPI_SCK

I do not have any uC development boards. Again, I do not even know what uC means. I am located on a farm, not a university.
I do not know how to find out which communication paths are 1-way and which are bidirectional.
I do not know how do find the the bandwidths of the signal. The GPIO wires lengths are 20 AWG 10"x2 wires. I do not know about their impedance.
I am not familiar with various termination schemes for transmitting data/information over communication cables.

 

[CWatters]

What is the purpose of the test kit? To test one possibly faulty sensor on one logger? Check that 1000s of products coming off a production line are good? Help field service engineers?

Perhaps listen to your advisor. In a production or QA environment you want test kit that is easy to use so you don't have to have an expensive engineer to operate it. Perhaps a box that you can connect to the sensor that tests the sensor and gives a pass/fail indication. Perhaps also generates a known output to check the data logger?

Can you get the data logger to test the sensor? Eg feed the sensor a known signal and see what the data logger records?

 

[adamaero]

Thanks for seeming to try to help. I got one useful suggestion from a different forum, and two confirmations that I could just use the pocket-sized oscilloscope I mentioned.

What is the purpose of the test kit? To test one possibly faulty sensor on one logger? Check that 1000s of products coming off a production line are good? Help field service engineers?

These are environmental sensors on a farm. There are ten sites with a data logger and each of the three kinds of senors at each site. I created a PCB board to make it easier for anyone to switch voltage and DPDT functionality via plug and play jumpers. Initially the test rig is to confirm I correctly designed the PCB. Then, the test rig is to troubleshoot why a data reading is incorrect. Additionally, they will be swapping out sensors and want a way to confirm they connected the sensor to the correct header. The ones that would be using this test rig is my adviser/boss (an average Joe), and whoever he hires in the future. Yet, I do not think an oscilloscope is hard to read. And I would make a brief manual on how to use it.

Perhaps listen to your advisor. In a production or QA environment you want test kit that is easy to use so you don't have to have an expensive engineer to operate it. Perhaps a box that you can connect to the sensor that tests the sensor and gives a pass/fail indication. Perhaps also generates a known output to check the data logger?

That is what I am asking. How? What would you do?
My boss wants this device to enable the user to troubleshoot if something is wrong. For example, we are getting incorrect data from an ultrasonic sensor (MB7380) operating on TTL. I do not know if the sensor is outputting the correct signal, or if the logger is not reading the sensor correctly.

Can you get the data logger to test the sensor? Eg feed the sensor a known signal and see what the data logger records?

The flexs Q4 does not appear to have that functionality.

 

[adamaero]

Should I be having this discussion on a different website? What would you suggest?
It seems as though I'm wasting a lot of time here explaining extraneous details, and without resolution.

 

[berkeman]

Should I be having this discussion on a different website? What would you suggest?
It seems as though I'm wasting a lot of time here explaining extraneous details, and without resolution.

I'll move your thread back to the EE forum to see if it gets any more replies. At least for me, I'm having a hard time understanding the system. You did post the block diagram I asked for though, so I'll try to spend some more time looking at it.

I don't think that having unskilled people try to use an oscilloscope to debug problems will work very well, though. For communication issues, you typically look at signal amplitude, rise and fall times, "eye diagrams" and so on. Improperly terminated comm cables can lead to spotty communication problems (due to jitter introduced by the reflections).

 

[berkeman]

Your diagram in post #8. I'm still trying to decode it...

 

[adamaero]

(There are two MB7380 ultrasonic sensors.)

 

[Tom.G]

Hi @adamaero,
A test set for the system will need to read everything the flexs Q4 is supposed to read, and then decide if what is read is 'Correct enough' to show a Go-NoGo result.

So the first step is to get a flexs Q4 working, and that is straight-forward debugging and troubleshooting. You put in a signal that you know is good and verify that you get the expected response.

Usually the easiest way to generate the known good signal is with a known good sensor of the same type that is used on the system. That is where general purpose test equipment (such as a 'scope, multimeter, frequency counter...) is needed. For instance you mention a problem with the range sensor. In the lab or workshop you apply power to the range sensor and aim it at a wall a known distance away. Make whatever other connections are needed and measure the sensor output with you test equipment. You don't say which of the range sensor output options you are using so you will have to fill in the details.

At this point you have one known good range sensor to connect to a flexs Q4.

Now see if the flexs Q4 responds to range sensor as expected. If not, back to debugging and troubleshooting, the flexs Q4 this time (or its program or maybe the wiring between them.)

Repeat the above steps with each of the sensors. Eventually you will get a complete working system.

This has all occurred in the lab or workshop so far. You probably have short wiring to the sensors and not a lot of electrical interference. Out at the work site many of the sensors will likely need rather long wiring, and long wires can make good signals into bad ones that can not be read. Try long connecting long wires in the lab where you have nice surroundings and lots of equipment.

Once you get this far, try adding some electrical noise (interference). An electric drill that runs from mains power will generate electrical noise. Don't bother trying a battery drill, they make very little interference. See if the system still works reliably when the electric drill is moved around close to various parts and wiring. You might have to use twisted shielded cable to get things working. Depending on the signal, sometimes a small capacitor across the signal input pins will help.

You can now take this known good system to the work site and check everything there. If there is a problem with particular sensors, try testing them with short signal wires.

Alright... that is how you start from zero to a working system.

A Go/NoGo test set for non-technical people is a good idea but is a significant project in itself.

A straight forward way of making a Go/NoGo test set is have a known good item connected to the same input signals as the item being tested. Then compare the two outputs. For digital logic testing (like the flexs Q4), the test set will be about twice as complex as the item tested. This is because you have to both generate the good signal AND compare the signals.

Don't get discourged, overall this is a normal system start-up situation. You just have to work it through one step at a time.

If the people at the work site are moderately competent, just swapping pieces until it works is the easiest method.

Please keep us posted on your progress.

Cheers,
Tom

 

[berkeman]

View attachment 227597
(There are two MB7380 ultrasonic sensors.)

So for your SPI sensor links, what datarate are they running at, and how long are the wired connections? You have said that you have not learned about wired bus terminations so far as an EE student (which is fine), but you will likely need to learn about them now if you want those data links to be reliable.

It sounds like you are being tasked with proving out the system after someone else has designed it. Do you have access to that system designer?

 

[adamaero]

Hi @adamaero,
A test set for the system will need to read everything the flexs Q4 is supposed to read, and then decide if what is read is 'Correct enough' to show a Go-NoGo result.

So the first step is to get a flexs Q4 working, and that is straight-forward debugging and troubleshooting. You put in a signal that you know is good and verify that you get the expected response.

[...]

Please keep us posted on your progress.

Cheers,
Tom

For the most part, the eight sites give good data. Sometimes one or two do not. It varies among the sites too.
Take rainfall for example:

Fig. 1. Several sites giving inaccurate data: no rainfall on this day--even though one site says that half-a-foot of rainfall occurred! Bad.

Fig. 2. Proof that no rainfall happened that day from the local airport.

Fig. 3. Shown is accurate data for another day (with two instances of an unreasonable spike). Good.

Fig. 4. Proof that rainfall happened (this other day) from the local airport.


---

For this sensor, I too thought, why not just wave your hand under the ultrasonic sensor and read it from the Q4...but from the data being collected, it seems that all these systems are working. It is just that some days there is highly inaccurate data.

 

[rbelli1]

Yet, I do not think an oscilloscope is hard to read. And I would make a brief manual on how to use it.

I don't think that having unskilled people try to use an oscilloscope to debug problems will work very well, though.

I agree with berkeman here. Assume your user will be willfully and purposefully ignorant about anything that is on an unfamiliar test equipment. I have worked in computer tech support. I had to routinely explain the difference between left and right to people. It seems they can't understand that left(on a computer) means precisely the same thing as left(on a shoe). If you describe the process exactly (press the button with STOP written on it) they will mess it up because it is an oscilloscope and they don't know how to use of those.

Ideally it will start the test once it detects the connection is complete and just outputs pass or fail. Plug in, pass or fail lights, unplug. Make sure they are labeled not just different colors. Some people can't tell the difference between certain colors especially red and green.

BoB

 

[adamaero]

I agree with berkeman here. Assume your user will be willfully and purposefully ignorant about anything that is on an unfamiliar test equipment. I have worked in computer tech support. I had to routinely explain the difference between left and right to people. It seems they can't understand that left(on a computer) means precisely the same thing as left(on a shoe). If you describe the process exactly (press the button with STOP written on it) they will mess it up because it is an oscilloscope and they don't know how to use of those.

Ideally it will start the test once it detects the connection is complete and just outputs pass or fail. Plug in, pass or fail lights, unplug. Make sure they are labeled not just different colors. Some people can't tell the difference between certain colors especially red and green.

BoB

Yes, but I may not be able to design such a system. "Output required signals (TTL, voltage, pulse, 1-wire)" part is doable. Although, I do not know how to create 9600 baud with 8 data bits, no parity bit, and one stop bit signal (for the TTL serial data).

What's more, the circuit needs to "evaluate output from sensors (serial TTL, analog voltage, 1-wire)." I presume a implementing a comparator works for the analog voltage--but what about serial data??

Do you have a resource I can read that will detail how to confirm if a digital signal is correct or not? Am I over-complicating it?

 

[berkeman]

I do not know how to create 9600 baud with 8 data bits, no parity bit, and one stop bit signal (for the TTL serial data).

Just use a uC or a laptop with a USB-to-Serial dongle.

but what about serial data??

Look at the serial protocol analyzers and interfaces like these from TotalPhase, they are extremely useful:

www.totalphase.com

Do you have a resource I can read that will detail how to confirm if a digital signal is correct or not?

There are specifications for rise time, fall time, voltage levels, etc. for each of the communication mechanisms you mention. However, if there are problems with these signals in your systems, they are likely due to improper/faulty cabling and termination schemes, not due to bad Tx/Rx parts.

 

[rbelli1]

https://www.mccdaq.com/Data-Translation
http://www.ni.com/en-us/shop/labview.html

If you want to use a computer. NI also sells interface hardware. Keithley, Advantech, Keysight, Omega and a bunch I am forgetting at the moment are also good sources for USB to whatever hardware.

Otherwise learn about Arduino. If it doesn't require lots of computation you can use that and get the whole thing in a handheld package.

Most of the manufacturers of micro-controllers have boards available. TI and NXP have some really inexpensive ones. https://www.infineon.com/cms/en/product/promopages/aim-mc/DAVE3-development-platform.html and Cypress have graphical interfaces for configuring their parts as well as dirt cheap boards. All have some variant that will connect directly into the Arduino ecosystem.

BoB

 

[Tom.G]

You show that different sites have different occassional bad readings. My first step would be to check and tighten all the wiring connections for the troublesome channels. It could be something as simple as a loose screw connection.

Other possibilities that come to mind are to see if the bad signals happen when there is a wind gust for instance; or maybe a bird landed on a sensor; or just change the troublesome sensor and see if that changes anything. (of course, even if changing the sensor fixes the problem it could still have been a loose connection to the sensor. )

Cheers,
Tom

 

[adamaero]

Just use a uC

What is a uC?

 

[adamaero]

Most of the manufacturers of micro-controllers

Most of #21 lists very general resources. For example, listing LabVIEW, Adruino, Cypress, etc is not helpful. But maybe I'm wrong.
Specifically, using an Adruino, would I be writing code with the digitalRead() function to evaluate if the digital two-pin sensor is giving a correct output?
Is it that simple?

I have not evaluated a digital signal before (besides simulations in Quartus II). The datasheet makes it sound like I need to do something more sophisticated:

...and the MB738X sensors have a TTL outputs. The output is an ASCII capital “R”, followed by four ASCII character digits representing the range in millimeters, followed by a carriage return (ASCII 13). The maximum range reported is 4999 mm (5-meter models).

A range value of 5000 or 9999 corresponds to no target being detected in the field of view. The serial data format is 9600 baud, 8 data bits, no parity, with one stop bit (9600-8-N-1).
​

MB7380 ultrasonic sensor
maxbotix.com/documents/HRXL-MaxSonar-WR_Datasheet.pdf#page=2

 

[berkeman]

What is a uC?

Microcontroller, like the Arduino that @rbelli1 suggested. Apologies, I thought I'd defined that term earlier in this thread, but it must have been in a different recent discussion thread.

 

[adamaero]

However, if there are problems with these signals in your systems, they are likely due to improper/faulty cabling and termination schemes, not due to bad Tx/Rx parts.

The GPIO pins are connected like this:

Sensor (not shown) → Hirschmann plug → four 20 AWG gauge wires → molex 3.0 microfit connector male → female → heat shrinked tubing in the middle of each of the four wires → GPIO header on Q4 logger

• They needed to connect them together (with the molex connectors) because that gauge of pre-crimped cables only come in 10" segments.
• The heat shrinked tubing part changes the gauge of the wires. It goes from 20 AWG to 25 or something higher.

Are you thinking that there are transmission life effects? or load impedance mismatch going on?

 

[berkeman]

Are you thinking that there are transmission life effects? or load impedance mismatch going on?

What are the lengths of wire and datarates involved? I saw SPI serial links mentioned earlier in the thread -- what is the SPI clock rate? If it's a normal fast rate and the wire is over a few inches, you should likely use "back termination" resistors to minimize reflections and the resulting signal ripple and closing eye diagram plot.

 

[berkeman]

Also, are you using twisted pairs for the signal+GND cables?

 

[adamaero]

What are the lengths of wire and datarates involved? I saw SPI serial links mentioned earlier in the thread -- what is the SPI clock rate? If it's a normal fast rate and the wire is over a few inches, you should likely use "back termination" resistors to minimize reflections and the resulting signal ripple and closing eye diagram plot.

I do not know the sensor cable length, but from the Hirschmann plug: Ten inches, molex connector, ten inches.

All I can find on the Q4 datalogger are instruction manuals, not datasheets.

 

[adamaero]

Also, are you using twisted pairs for the signal+GND cables?

The only connections are the precrimped wires to the molex connector sockets, and whatever's under the tubing. Each wire is independent.

 

[berkeman]

All I can find on the Q4 datalogger are instruction manuals, not datasheets.

Does it specify SPI datarates anywhere? Sorry if you already posted it and I missed it.

 

[adamaero]

Does it specify SPI datarates anywhere? Sorry if you already posted it and I missed it.

"6 GPIO pins and also contains a High Speed UART, SPI bus and I2C Bus"

"Includes 2X High Speed 3.3V (5V Tolerant) TTL Serial Ports, 1X High Speed SPI Interface, 1X I2C Interface with onboard pullups, 8X GPIO Pins"

I can ask the company for a numerical value.

1. Is "high speed" is a specific value?
2. Also, why SPI? Is this one SPI? Why isn't it UART?

• GPIO5/UART2_RX/SPI_IN

 

[berkeman]

Yeah, asking the manufacturer might be a good idea, and also ask if there are any back-termination resistors included on their high-speed communication lines.

 

[Baluncore]

Designing from the top, down;
After building a data logger you can plug in your 'test unit' to monitor functionality and QC.
In the field you can connect your 'test unit' to diagnose faults that may be present.

You will need to tap into each data logger's circuits in a number of places to check operation. That must be done without disturbing the unit under test. You could insert an extra plug&socket tap as a wedge between existing mated connectors. That would not be convenient with screw terminals.

The alternative would be to provide a standard external field test connector that gives access to the majority of internal connections on all the data loggers built. Your test unit can then evolve as further tests are developed during the manufacturing and testing phases.

 

[adamaero]

Designing from the top, down;
After building a data logger you can plug in your 'test unit' to monitor functionality and QC.
...

Yes, that's the easy part.

... communication lines.

It's only a few feet. The site is remote, but powered by solar panels. Transmission line effects are negligible.