TTL, voltage, one-wire test rig

  • #1
97
1
Thread moved from the technical forums, so no Homework Template is shown
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
 

Answers and Replies

  • #2
berkeman
Mentor
59,015
9,110
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?
 
  • #3
97
1
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).
 
Last edited:
  • #4
97
1
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.)
 
  • #5
97
1
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 DigiKey, 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...
 
  • #7
berkeman
Mentor
59,015
9,110
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.
 
  • #8
97
1
header_pinout-300x300.png
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
upload_2018-7-2_15-40-17.png

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.
 

Attachments

  • Like
Likes berkeman
  • #9
CWatters
Science Advisor
Homework Helper
Gold Member
10,532
2,298
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?
 
  • Like
Likes berkeman
  • #10
97
1
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.
 
Last edited:
  • #11
97
1
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.
 
  • #12
berkeman
Mentor
59,015
9,110
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).
 
  • Like
Likes rbelli1
  • #13
berkeman
Mentor
59,015
9,110
Your diagram in post #8. I'm still trying to decode it...
 
  • #15
Tom.G
Science Advisor
3,695
2,384
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 occured 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
 
  • Like
Likes Asymptotic and berkeman
  • #16
berkeman
Mentor
59,015
9,110
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?
 
  • #17
97
1
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:
upload_2018-7-4_13-59-32.png

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.


upload_2018-7-4_14-31-3.png

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


upload_2018-7-4_14-14-47.png

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


upload_2018-7-4_14-15-54.png

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.
 

Attachments

Last edited:
  • #18
rbelli1
Gold Member
988
377
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
 
  • Like
Likes berkeman
  • #19
97
1
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?
 
  • #20
berkeman
Mentor
59,015
9,110
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.
 
Last edited:
  • Like
Likes adamaero
  • #21
rbelli1
Gold Member
988
377
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. Infineon 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
 
  • Like
Likes berkeman
  • #22
Tom.G
Science Advisor
3,695
2,384
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. :oops:)

Cheers,
Tom
 
  • Like
Likes adamaero and dlgoff
  • #24
97
1
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
 
  • #25
berkeman
Mentor
59,015
9,110
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. :smile:
 
  • Like
Likes adamaero

Related Threads on TTL, voltage, one-wire test rig

  • Last Post
Replies
4
Views
2K
  • Last Post
Replies
9
Views
8K
  • Last Post
Replies
8
Views
3K
  • Last Post
Replies
10
Views
2K
  • Last Post
Replies
6
Views
11K
  • Last Post
Replies
1
Views
16K
  • Last Post
Replies
1
Views
6K
  • Last Post
Replies
6
Views
3K
  • Last Post
Replies
1
Views
5K
  • Last Post
Replies
4
Views
4K
Top