Can you mimic the output of a digital sensor for testing purposes?

Martythed

Hello Stampers.

I’m working on a project using the BS2-IC with a 0831ADC, MC14489 LED driver and external sensors (analog or digital) to operate a “relay controller” that has four relays as well as a 4-digit LED display to monitor the input, such as temperature, RPM, voltage, distance…. whatever. Basically, the four relays operate in sequence based on the input from the sensor and the BS2 code and can control various functions.

Now my problem.

I can mimic the output from analog sensors (maximum of 5 vdc) by using a 0 to 5vdc test voltage. This enables me to check the LED display readout as well as testing to be sure that the relays activate at the correct level, whatever that may be……. voltage, RPM, temperature and such. However, I can’t find a way to mimic the output of, say, a DS1620 digital sensor so I can check operation of the relay controller and the LED readout.

Perhaps a second BS2 could be programmed to mimic the output of various digital sensors and that output used for testing purposes. For example, a temperature of 25C causes the DS1620 to output 000110010 (nine bits) and I suspect that some other digital sensors are similar. Could this bit value just be sent as “one-shot” into the BS2 under test? Would there be clock, synch or other problems? Would this be a worthwhile project in itself?

Finally, before I go, the project I’m working on, the “relay controller”, is up and running with the LED display and looks OK on a breadboard using an analog sensor (LM34). The DS1620 works with the LED display but I still have no way to check it with the relay controller. I have schematics for the controller, LED circuits and also the code for use with a 0 to 5vdc output sensor and hope to put it on the Forum.

Thanks for any ideas.

Marty

Franklin

Depending on your code (what the controller does with the information it gets from the sensor) you could write code to trigger the relay in test mode and output the sensor value to the serial monitor to see if it is correct. That is not the easiest thing but probably less than creating sensor simulators.

SRLM

I've played around with this (in CS lingo it's called making a Mock object), but came to the conclusion that it's no good: all the problems that I'm likely to encounter will arise due to a misreading of the datasheet. With a mock object that misreading will just be codified, not found and corrected.

Of course, this applies only to complex external components.

Martythed

Thanks for the reply, Franklin.

I’m not quite sure what you mean. Are you talking about creating code and feeding it directly into the project BS2 under test?

So, if I want to test the response of a project that would use, say, a DS1620, some code could be written and put directly into the project BS2. In other words, my PC running the Basic Stamp Editor becomes the “sensor”, at least for test purposes. For example, code might be written to mimic a DS1620 reading a temperature of 25C, hold that for 5 seconds (or whatever) then output code for 30C for 5 seconds and so on. Likewise, code could be written for a digital RPM sensor that emulates various RPMs. Perhaps the output could be monitored with the DEBUG function(?)

Actually, code could probably be written for many digital sensors (although I suspect it’s a little over my head), and it would be especially useful for sensors that would be difficult to emulate, such as an accelerometer. However, there’s one big IF: One would have to know what output produces what result. For example, a digital RPM sensor outputs a certain digital value at 3000 RPM……. but what is that value; what is it at 5000RPM? The same with an accelerometer; what value produces what result? Do sensor manufacturers publish this information? The DS1620 has some output values for several temperatures of use, but not that many; perhaps there’s some way to interpolate between two values(?).

I wonder if something like this would be of interest to those who do a lot of work with various sensors? A possible project, perhaps?

Thanks,

Marty

Franklin

I was thinking even easier than you. If the DS1620 puts out a code for 25c and your program reads that somewhere in your code that is turned into a value of "25c" and your code then acts upon that

if temp_c > 25 then <turn on fan relay>

If, in your test program, you set temp_c to 26 then the relay should turn on.

Martythed

OK Franklin......... I see what you mean.

I looked around and didn't see any values for the DS1620 other than the few that are in the data sheet. As I mentioned, I can get the DS1620 to read on my LED display, but without knowing how to take a particular temperature and turn it into code I'm sort of out of luck with programming the relays. I guess I'm going to have to stick to analog sensors and the 0831 ADC for the time being.

Anyway, it would have been an interesting project to emulate various digital sensors with a PC , load the code into the BS2 and see what happens to a particular project. However, getting the necessary values for even a few sensors would be quite a job, also, the post above from SRLM doesn't sound all that encouraging.

Thanks,
Marty

SRLM

To elucidate on my point further, the problem is that we don't really know how a chip will react until we test it out. And the only way to test is by writing some code and watching what happens with the proper instrumentation (an oscilloscope or logic analyzer). It's these edge cases that make it difficult to write mock drivers. And once there's written they have little value: drivers very rarely change (after all, the hardware is etched in silicon).

The better way of overcoming this is proper separation of concerns. After writing and manually testing a low level driver that does nothing but interface to a chip you can make a mock of that so that when you call a function it returns a predefined value. Then the rest of your code can run off that and you'll get consistent results for testing.

Tracy Allen

Marty,

+1 what SRLM said. If it is a sensor new to you, then the sensor is the best simulator of itself, so that you can address protocol and timing issues. On the other hand, if you have an issue about calculations that the stamp will have to do to average or process the data in some way, then it is quite useful to feed your subroutines simulated data that does not necessarily have to come from the sensor. In fact that might be impractical to get the sensor to the extreme values or conditions or speed where you want to be sure that your Stamp code will work correctly.

I'm not clear on why you would want to simulate the sensor anyway. Is it because you want to try out code for sensors you don't have in hand?

Martythed

Tracy,

My interest in emulating a digital sensor came from how easy it is to substitute a DC voltage for the output of the LM34 analog temperature sensor and then observing the response of my project to the “temperatures” generated by the test voltage. This, of course, eliminates the need for actually heating the LM34 with a lighter or some such thing.

So, I was thinking if I could find the output values (such as the values for different temperatures) of a digital sensor, I could feed these values into a project and see what the response would be to changing temperatures. For another example: An RPM encoder might be emulated to show how changing speeds affect a project. No real sensor would be needed; the PC would become the “sensor” and generate the correct code, or the correct pulses per minute.

Looking into it a little more, however, I see that it would be impractical to get the needed information for even a small number of digital sensors.

Still, it would be convenient to have a “library” of sensors sitting on ones hard drive, ready when needed.

Regards,
Marty

Tracy Allen

That is what we mean. The protocol and timing required to read a sensor may be distinguished from the actual numerical values that it produces. You can feed in bogus numerical values from anywhere to see how the rest of the program responds. Those values could come from the PC as you type them in, or they could be generated on the BASIC Stamp itself with a subroutine for that purpose.

A case in point is the MSI barometer. One command reads in a several calibration values, which are then used in mathematical formulae to convert raw readings to actual barometric pressure. You can use the typical values provided in the data sheet to see if the math comes up with the same answers that they provide, and that can be separated from the actual process of reading the sensor using the SPI or I2C protocols, which may have its own issues if you are new to it. Another independent step involves the numerical values that you get from the sensor, absolute pressure, and conversion to standardized barometric pressure or altitude. And then from that, how that information is displayed or acted upon. They can all be tested to some degree independently by providing numbers from outside.

Martythed

Thanks for the comments, Tracy…….. most interesting.

I’m beginning to suspect that looking for ways to emulate various digital sensors on a PC is a dead end. I’ll probably just concentrate on analog sensors, at least for the time being, and see what’s out there and which ones may be of use.

Marty