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.
____________________

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.
____________________

Overview of 1-Wire Technology and Its Use

 

What do you mean by "1-wire"?

Why wouldn't serial TTL be considered digital?

 

You have a mix of analog and logic signals and protocol (one wire).

I would think of using a PSOC 5LP or 4, start with 5LP. may be able to
squeeze into 4 later to cut cost.

The 5LP can talk to serial, I2C, SPI, One Wire, UART, Parallel.

For the analog portion it has on onboard 12 bit SAR and/or 20 bit DelSig, analog
muxes to handle more than one input, and it has onboard Vref. Even has onboard
DSP to filter signals should you need that. And 4 OpAmps onboard, DACs...

Would require you to be able to write C, nothing too difficult though.

Attached is a list of all the resources on the 5LP. Counters, timers, logic, LUTs....

Board you would start with is $ 10, IDE and Compiler free.

http://www.cypress.com/products/psoc-creator-integrated-design-environment-ide

http://www.cypress.com/documentatio...oc-5lp-prototyping-kit-onboard-programmer-and




This is not a trivial design, learning IDE challenging but rewarding. Plenty
or training videos at Cypress.com, start with "PSOC Creator 101" series of
videos.

Regards, Dana.

 

Okay, I misunderstood your post. I was thinking your sensors had a single output that you were describing as a 1-wire analog TTL signal.

 

There can be analog 2-wire, such as a 5-20mA current loop, or a so-called 1-wire digital (TTL or other digital signal) which actually uses two wires, a signal and return.
Be sure you keep the two distinct in your discussion of the circuits.

 

There can be analog 2-wire, such as a 5-20mA current loop, or a so-called 1-wire digital (TTL or other digital signal) which actually uses two wires, a signal and return.
Be sure you keep the two distinct in your discussion of the circuits.

Where did I mix them up?

 

Where did I mix them up?

It wasn't clear that you had them separate in your description.
If you did, then that's fine.

 

You have a mix of analog and logic signals and protocol (one wire).

I would think of using a PSOC 5LP or 4, start with 5LP. may be able to
squeeze into 4 later to cut cost.

The 5LP can talk to serial, I2C, SPI, One Wire, UART, Parallel.

For the analog portion it has on onboard 12 bit SAR and/or 20 bit DelSig, analog
muxes to handle more than one input, and it has onboard Vref. Even has onboard
DSP to filter signals should you need that. And 4 OpAmps onboard, DACs...

Would require you to be able to write C, nothing too difficult though.

Attached is a list of all the resources on the 5LP. Counters, timers, logic, LUTs....

Board you would start with is $ 10, IDE and Compiler free.

http://www.cypress.com/products/psoc-creator-integrated-design-environment-ide

http://www.cypress.com/documentatio...oc-5lp-prototyping-kit-onboard-programmer-and

View attachment 155476


This is not a trivial design, learning IDE challenging but rewarding. Plenty
or training videos at Cypress.com, start with "PSOC Creator 101" series of
videos.

Regards, Dana.

The objective is to test if the sensors are correctly connected to the data logger. Excluding the protocol signal testing (one wire), would the pocket oscilloscope be the quickest way to test everything else? I do not get how to test a GPIO configuration with an oscilloscope. What about the other end of this picture? Is that why a microcontroller is needed?

One sensor has two GPIO pins (one for GPIO and one for UART). Another has two pines (GPIO5/UART2_RX/SPI_IN and GPIO6/SPI_SCK: )

 

Yes, if you do not need protocol decode and you are not in
embedded developer mode definitely scope would be handy.
Even a PLC with a GUI front end, or a simple USB DAQ would
be a solution.

Regards, Dana.

 

The objective is to test if the sensors are correctly connected to the data logger. Excluding the protocol signal testing (one wire), would the pocket oscilloscope be the quickest way to test everything else? I do not get how to test a GPIO configuration with an oscilloscope. What about the other end of this picture? Is that why a microcontroller is needed?

What it really comes down to is what level of information is sufficient for YOU to be able to accurately and reliably interpret it so as to determine whether it is working correctly and, if not, what the problem is. If you have a strong enough understanding of the real time signals that you will see on a scope to do that, then you can use a scope. But if you aren't going to be able to tell if the traffic back and forth is doing what it should, then you need something different.

 

What it really comes down to is what level of information is sufficient for YOU to be able to accurately and reliably interpret it so as to determine whether it is working correctly and, if not, what the problem is. If you have a strong enough understanding of the real time signals that you will see on a scope to do that, then you can use a scope. But if you aren't going to be able to tell if the traffic back and forth is doing what it should, then you need something different.

Well, I do not think it's really for me anyway. I'm only there for two months. And then it is up to average Joes to determine if the sensor or the board is at fault. Then again, an oscilloscope is not that hard to use. I could even write some instruction manual for the application at hand.

Overall, I do not know exactly how to interpret a GPIO signal. Do you know of a useful resource I could read?

 

Well, I do not think it's really for me anyway. I'm only there for two months. And then it is up to average Joes to determine if the sensor or the board is at fault. Then again, an oscilloscope is not that hard to use. I could even write some instruction manual for the application at hand.

Overall, I do not know exactly how to interpret a GPIO signal. Do you know of a useful resource I could read?

GPIO is simple General Purpose Input Output. The device can either output a logic value on that pin or read a logic value applied to that pin. There's not much more to it than that. What you need to know is what the signals mean and how to interpret them. That's entirely dependent on who designed the system. If they are interfacing with a well-documented sensor, then that's what you need to learn about.

As for the test system you are trying to design, you need to take into account the average Joes that are going to be using it. Imagine you were having trouble with your TV and paid someone to design a test system for you to use and what you got was a screen full of nothing but ones and zeroes. All the data you need is there, but have the guys you paid done you any favors? Found out what your customer needs! Don't cobble something together that you think might work, design something that WILL work because it is intentionally designed to satisfy your customers needs.

 

GPIO is simple General Purpose Input Output. The device can either output a logic value on that pin or read a logic value applied to that pin. There's not much more to it than that. What you need to know is what the signals mean and how to interpret them. That's entirely dependent on who designed the system. If they are interfacing with a well-documented sensor, then that's what you need to learn about.

As for the test system you are trying to design, you need to take into account the average Joes that are going to be using it. Imagine you were having trouble with your TV and paid someone to design a test system for you to use and what you got was a screen full of nothing but ones and zeroes. All the data you need is there, but have the guys you paid done you any favors? Found out what your customer needs! Don't cobble something together that you think might work, design something that WILL work because it is intentionally designed to satisfy your customers needs.

I know what GPIO is theoretically. Google helped with that. At this point, I am just going to have them order the hand-held oscilloscope and go from there. Is it a square wave I'm looking for? Do you have a resource that describes or is related to interpreting digital signals on a scope?

 

I know what GPIO is theoretically. Google helped with that. At this point, I am just going to have them order the hand-held oscilloscope and go from there. Is it a square wave I'm looking for? Do you have a resource that describes or is related to interpreting digital signals on a scope?

You are looking for whatever signal the documentation for the sensor says is required in order to successfully interface to that sensor. So start with the documentation for the sensors you are using.

 

You are looking for whatever signal the documentation for the sensor says is required in order to successfully interface to that sensor. So start with the documentation for the sensors you are using.

It is the ultrasonic sensor (MB7380).
maxbotix.com/documents/HRXL-MaxSonar-WR_Datasheet.pdf#page=2

...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).​

What will I be looking for on the scope?

 

It is the ultrasonic sensor (MB7380).
maxbotix.com/documents/HRXL-MaxSonar-WR_Datasheet.pdf#page=2

...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).​

What will I be looking for on the scope?

You are looking for serial data at 9600 baud (so about 104 microseconds per symbol) with 8 data bits, no parity bit, and one stop bit. You are looking for a sequence of six packets. The first contains the 8-bit ASCII code for a capital 'R' (which is 82). The next four each contain the ASCII codes for a decimal digit (48 for '0' and 55 for '9'). The last contains the the value 13. These are most likely transmitted lsb first.

 

So I looked up "serial data" and "oscilloscope."

• electronics.stackexchange.com/questions/17562/how-to-read-serial-data-from-oscilloscope
• • @12:20

Do these digital signals (GPIO) fit within 3 MHz? That's the maximum the hand-held scope can accurately read: