Testing a Microcontroller with a Function Generator

[gregolive]

Hello,

I have more of a mechanical background so I was looking to get some help from someone with an electrical background with this. I am trying to use a BK Precision Function Generator (datasheet: https://bkpmedia.s3.amazonaws.com/downloads/manuals/en-us/4017A_manual.pdf) to send a signal to a Teensy 3.6 microcontroller at around 80kHz to see if it able to read and write an analog input at this frequency.

I have an Arduino sketch that will log the data to a microSD on the Teensy, but I am unsure about exactly how to hook everything up properly. I think that I will need to have a coax cable connected to the output of the function generator and then have it split so that I can connect to an analog input pin and ground pin on the Teensy, but I am concerned about the voltage output of the function generator. From what I can tell the pins on the Teensy are rated to 3.3 V and in the specifications of the function generator datasheet there are multiple output types listed, all with different voltages, and I am unsure which one pertains to my situation. One other possible issue is that the ADCs on the Teensy have a reference voltage of 1.2 V so does that mean I have to send the analog signal in at 1.2 V?

This is my first time using a function generator and I am hoping to not fry my board, so any advice on this would be greatly appreciated! Thanks in advance!

Greg

 

[aethergravitics]

You may want to consider employing an opto isolator ic between your function generator output and your Teensy input if you are worried about frying your microcontroller.

 

[Baluncore]

Welcome all, to PF.

Will you be using a square or a sine wave? Keep the signal low voltage at the start. Do you know what is used as the zero reference for the A-D converter? That may need to be connected to the signal generator reference.
If you make a voltage divider from a couple of 10k resistors, that will protect the analogue input from unfortunate voltages during the learning exercise. Once you see the converted data you will know the limits to the analog inputs.

Please post a link to the teensy 3.6 general or analog input specs.

Where did you get your sketch from? Is there a link? or can yoau attach it to a post?

 

[NTL2009]

And I'd also start at a much lower frequency just to test your code. Offhand, I'm not sure if 80 KHz (you'll need > 160,000 samples per second) is challenging for that micro controller (consider interrupts), but I'm pretty sure you won't be able to write each cycle to an SD card.

Hmmm, are you looking to actually count the transitions, or just looking for the presence/absence of a signal ~ 80 KHz? You could rectify it, and use a small capacitor to provide a DC voltage whenever the signal is present. Is that enough?

 

[Windadct]

Also - there is a Serial Monitor function in the IDE, pretty easy to see if you are getting the analog signal converted properly.

 

[gregolive]

You may want to consider employing an opto isolator ic between your function generator output and your Teensy input if you are worried about frying your microcontroller.

Thanks for the reply aethergravitics! Would using a volatge divider circuit with resistors complete the same function as an opto isolator ic? I would prefer that option as I already have some resistors that I could use but don't have an opto isolator on hand.

 

[gregolive]

Welcome all, to PF.

Will you be using a square or a sine wave? Keep the signal low voltage at the start. Do you know what is used as the zero reference for the A-D converter? That may need to be connected to the signal generator reference.
If you make a voltage divider from a couple of 10k resistors, that will protect the analogue input from unfortunate voltages during the learning exercise. Once you see the converted data you will know the limits to the analog inputs.

Please post a link to the teensy 3.6 general or analog input specs.

Where did you get your sketch from? Is there a link? or can yoau attach it to a post?

Thanks for the reply Baluncore! To answer your questions...

I was thinking a sine wave, but is there any difference between using a sine or square wave?

I believe the zero reference for the ADC is 1.2 V, is that the voltage I would have to input from the function generator?

I wasn't able to find an analog input spec, but this post (https://forum.pjrc.com/threads/41911-Teensy-3-6-ADC-resolution) in the Teensy forums discusses the ADCs of the Teensy 3.6. From what I can gather it has 25 analog inputs and 2 ADCs with max 13 bit resolution. I remember reading somewhere else that the ADCs have a clock speed of 25 MHz and someone said each ADC has a total sample rate of 800,000 samples per second.

This is the sketch (https://forum.pjrc.com/threads/43834-Real-low-latency-logging-for-Teensy-3-5-3-6-SDIO-SD) posted in the Teensy forums. The user who posted it says it has 40 ms max latency which corresponds to writes of 5 MB/s.

 

[gregolive]

And I'd also start at a much lower frequency just to test your code. Offhand, I'm not sure if 80 KHz (you'll need > 160,000 samples per second) is challenging for that micro controller (consider interrupts), but I'm pretty sure you won't be able to write each cycle to an SD card.

Hmmm, are you looking to actually count the transitions, or just looking for the presence/absence of a signal ~ 80 KHz? You could rectify it, and use a small capacitor to provide a DC voltage whenever the signal is present. Is that enough?

Hi NTL2009, thanks for the reply! I'm working on a project where I want to sample at 60,000 S/sec (10,000 S/sec from 6 sensors) so I was hoping to test the limits of the microcontroller by first attempting to read and write a high frequency sine wave, to make sure it is possible. I was going to import the log file into a program like Matlab afterwards to see if the whole signal has been captured.

According to the user who posted the Arduino sketch (https://forum.pjrc.com/threads/43834-Real-low-latency-logging-for-Teensy-3-5-3-6-SDIO-SD) I will be using to write the data to an SD, write times of 5MB/s are possible, but I am not sure how realistic that is. Do you think that considers interrupts?

In terms of a rectifying the signal would this mean the analog to digital converters won't convert the signal to digital?

 

[gregolive]

Also - there is a Serial Monitor function in the IDE, pretty easy to see if you are getting the analog signal converted properly.

Thanks for the reply Windadct! I am able to use the Arduino IDE with the Teensy, but do you think the serial monitor is able to display a signal at this frequency? I am also interested in writing the data to an SD card at this frequency, because from what I can tell the ADCs on the Teensy 3.6 are able to handle 80,000 S/sec, but I am unsure if I am able to write the data at this sample rate.

 

[NTL2009]

Hi NTL2009, thanks for the reply! I'm working on a project where I want to sample at 60,000 S/sec (10,000 S/sec from 6 sensors) so I was hoping to test the limits of the microcontroller by first attempting to read and write a high frequency sine wave, to make sure it is possible. I was going to import the log file into a program like Matlab afterwards to see if the whole signal has been captured.

According to the user who posted the Arduino sketch (https://forum.pjrc.com/threads/43834-Real-low-latency-logging-for-Teensy-3-5-3-6-SDIO-SD) I will be using to write the data to an SD, write times of 5MB/s are possible, but I am not sure how realistic that is. Do you think that considers interrupts?

In terms of a rectifying the signal would this mean the analog to digital converters won't convert the signal to digital?

But you can't sample an 80,000 Hz signal at 60,000 reads per second. Nyquist has something to say about that, and I've never known him to be wrong about it (well, you can sample it, but you get confusing aliasing that probably negates what you are trying to do).

It depends how you are trying to write. That 5MB/S , from your link says:

"With a worst case latency of 40ms and 200kb worth of buffers, 5MB/s are possible."

So that's an average rate of writing a large block of data. If you are doing something like this at 60,000/second:

1) Sample ADC
2) Write sample ADC value to file
3) After 1/60,000 of a second (from previous sample time), loop back to step 1

You will have a problem, as you will incur a 40 msec latency for each write. So you can buffer them into larger blocks, but then test whether your 1/60,000 second loop can continue and the latency is processed in the background. That is very system dependent, so it may be easiest to just test for it.

I'm not really much of a programmer and have not worked much with interrupts, you'll need to get the details on that elsewhere, but I know the technique might apply for this sort of thing.

If you rectify the signal, that will allow you to detect whether the signal is active or not. You just get a DC value while the signal is present, and that signal quickly goes to zero DC if the signal is off. But that doesn't sound like what you are trying to simulate anyhow?

 

[Baluncore]

Would using a volatge divider circuit with resistors complete the same function as an opto isolator ic? I would prefer that option as I already have some resistors that I could use but don't have an opto isolator on hand.

An opto-isolator is used to isolate digital data. It is not suitable for analogue signals. A voltage divider is the way to go, but there are complications due to the input voltage offset, (see later).

I was thinking a sine wave, but is there any difference between using a sine or square wave?

Your "sinewave" answer confirms you are recording the waveform and not just the digital state, or the presence of a digital signal.

I believe the zero reference for the ADC is 1.2 V, is that the voltage I would have to input from the function generator?

The analogue converter will have a minimum and a maximum input voltage that can be converted. If you select the internal 1.2V analogue reference for the ADC then it may convert inputs between 0V and 1.2V to the digital representation. To digitise a sinewave, the input would need to be centred on 0.6V, not on ground. The peak to peak amplitude would need to be less than 1.2V total. If the signal generator cannot produce that output offset then you will need to offset the signal with external hardware.
I have still not seen sufficient documentation to know what really happens.

 

[gregolive]

But you can't sample an 80,000 Hz signal at 60,000 reads per second. Nyquist has something to say about that, and I've never known him to be wrong about it (well, you can sample it, but you get confusing aliasing that probably negates what you are trying to do).

It depends how you are trying to write. That 5MB/S , from your link says:

"With a worst case latency of 40ms and 200kb worth of buffers, 5MB/s are possible."

So that's an average rate of writing a large block of data. If you are doing something like this at 60,000/second:

1) Sample ADC
2) Write sample ADC value to file
3) After 1/60,000 of a second (from previous sample time), loop back to step 1

You will have a problem, as you will incur a 40 msec latency for each write. So you can buffer them into larger blocks, but then test whether your 1/60,000 second loop can continue and the latency is processed in the background. That is very system dependent, so it may be easiest to just test for it.

I'm not really much of a programmer and have not worked much with interrupts, you'll need to get the details on that elsewhere, but I know the technique might apply for this sort of thing.

If you rectify the signal, that will allow you to detect whether the signal is active or not. You just get a DC value while the signal is present, and that signal quickly goes to zero DC if the signal is off. But that doesn't sound like what you are trying to simulate anyhow?

Thanks for your help, that makes more sense now! So basically that script would be unable to read and write the data at the same time? Originally I thought 40 ms latency meant that it writes the data every 40 ms, but would still be reading at the same time to prepare for the next write, so I must have misunderstood. I am hoping to get this set up early this coming week so will be able to find out if it is able to read and write at the same time.

 

[gregolive]

To digitise a sinewave, the input would need to be centred on 0.6V, not on ground. The peak to peak amplitude would need to be less than 1.2V total. If the signal generator cannot produce that output offset then you will need to offset the signal with external hardware.

To center the input on something other than ground would this mean putting the wire that usually goes to ground somewhere else? And by external hardware are you referring to a voltage divider or something else?

I have still not seen sufficient documentation to know what really happens.

I've been looking around, but unfortunately I haven't been able to find much documentation on the Teensy 3.6.

 

[Baluncore]

To center the input on something other than ground would this mean putting the wire that usually goes to ground somewhere else?

Not necessarily. To digitise a DC signal, the analogue grounds on the signal generator and on the A to D converter should be common at one point. It may be necessary to produce a DC offset of the input signal to centre it in the ADC input range. That might be dialled up on the signal generator or created by external components.

 

[NTL2009]

Thanks for your help, that makes more sense now! So basically that script would be unable to read and write the data at the same time? Originally I thought 40 ms latency meant that it writes the data every 40 ms, but would still be reading at the same time to prepare for the next write, so I must have misunderstood. I am hoping to get this set up early this coming week so will be able to find out if it is able to read and write at the same time.

I took "latency" to mean the overhead to write 1 byte or many bytes, kind of like the "seek time" on a hard drive if you are familiar with that. Which could be up to 40 msec in this case. But it might mean something else.

I will suggest you do what I would do in a case like this - read the specs, understand them as best you can, then write a little test program to validate your knowledge. Writing to Flash has some complexities to it that are usually pretty well 'hidden' from the operating system commands, so you probably really need to test it with your OS to see how it reacts. Which is fine, it is best to start a larger project by programming/building smaller blocks so you understand each, and then try putting them together. That process always worked well for me. And it 'sticks' in my brain better when I actually do it and experience the results.

I was never all that fluent in flash details, and it was a while ago, so I may be mis-remembering and/or spewing outmoded info, but that's OK, because you are going to test it on your own. But from what I recall, writing to flash works in non-obvious ways, 'hidden' from the user, but can bite (byte?) you if you are pushing things like this. I recall that flash can only write an entire "block" of data (block size depends on the device) - it can't really change one byte within that block. It appears to from a user perspective, but if you change one byte, it actually has to read the block, modify that one byte, and then rewrite that block. So changing a byte or a changing an entire block may take a similar amount of time. And that is probably why that reference you linked talked about writing X number of Y sized blocks, to achieve a 5 MB/sec average write speed.

Another consideration - flash memory has a 'wear out' problem. Data can only be written so many times before it may become unreliable. So if you have 1K blocks, you could write a byte at a time (1024 writes), versus buffering 1024 bytes in memory, and writing a block (1 write). The byte-by-byte write will wear out in 1024th the time.

It will really depend on your OS and how you program this, but the flash writing may be able to happen in the background while you read your ADC, or your program will just sit and wait for the flash write to complete before proceeding. If it waits, you won't be able to read the input any faster than you can write (which may be every 40 msec?). If it can do the write/wait in the background, you might be OK, unless it can't keep up. Like if you buffer up 1024 bytes, and write every 1024th sample - you may be OK if the writes are faster than the time it takes to make 1024 reads of the ADC.

Try bench-marking this on your own. If the first method you try won't work, you'll know you need to try another. A caution on bench marking though - this will only tell you the limit for that part. Use what you learn to check the worst case specs on the part to make sure it will work in those cases, especially if it is important that this works across multiple devices.

Good luck, and let us know how you do. Sounds like a fun little project.

 

[Windadct]

"do you think the serial monitor is able to display a signal at this frequency?"

Haha -- no I really do not know why I did not think this through, the baudrate isn't even high enough!

 

[Baluncore]

I am able to use the Arduino IDE with the Teensy, but do you think the serial monitor is able to display a signal at this frequency?

The serial monitor will be a two-state digital signal. That is insufficient to show sinewaves.
The ADC signal is a 2¹² = 4096 state signal representing an analogue input.

 

[gregolive]

Not necessarily. To digitise a DC signal, the analogue grounds on the signal generator and on the A to D converter should be common at one point. It may be necessary to produce a DC offset of the input signal to centre it in the ADC input range. That might be dialled up on the signal generator or created by external components.

Okay that makes sense! I will be playing around with the signal generator tomorrow so hopefully I can figure out if I can dial it up on it then. Thanks for all the help!

 

[gregolive]

I took "latency" to mean the overhead to write 1 byte or many bytes, kind of like the "seek time" on a hard drive if you are familiar with that. Which could be up to 40 msec in this case. But it might mean something else.

I will suggest you do what I would do in a case like this - read the specs, understand them as best you can, then write a little test program to validate your knowledge. Writing to Flash has some complexities to it that are usually pretty well 'hidden' from the operating system commands, so you probably really need to test it with your OS to see how it reacts. Which is fine, it is best to start a larger project by programming/building smaller blocks so you understand each, and then try putting them together. That process always worked well for me. And it 'sticks' in my brain better when I actually do it and experience the results.

I was never all that fluent in flash details, and it was a while ago, so I may be mis-remembering and/or spewing outmoded info, but that's OK, because you are going to test it on your own. But from what I recall, writing to flash works in non-obvious ways, 'hidden' from the user, but can bite (byte?) you if you are pushing things like this. I recall that flash can only write an entire "block" of data (block size depends on the device) - it can't really change one byte within that block. It appears to from a user perspective, but if you change one byte, it actually has to read the block, modify that one byte, and then rewrite that block. So changing a byte or a changing an entire block may take a similar amount of time. And that is probably why that reference you linked talked about writing X number of Y sized blocks, to achieve a 5 MB/sec average write speed.

Another consideration - flash memory has a 'wear out' problem. Data can only be written so many times before it may become unreliable. So if you have 1K blocks, you could write a byte at a time (1024 writes), versus buffering 1024 bytes in memory, and writing a block (1 write). The byte-by-byte write will wear out in 1024th the time.

It will really depend on your OS and how you program this, but the flash writing may be able to happen in the background while you read your ADC, or your program will just sit and wait for the flash write to complete before proceeding. If it waits, you won't be able to read the input any faster than you can write (which may be every 40 msec?). If it can do the write/wait in the background, you might be OK, unless it can't keep up. Like if you buffer up 1024 bytes, and write every 1024th sample - you may be OK if the writes are faster than the time it takes to make 1024 reads of the ADC.

Try bench-marking this on your own. If the first method you try won't work, you'll know you need to try another. A caution on bench marking though - this will only tell you the limit for that part. Use what you learn to check the worst case specs on the part to make sure it will work in those cases, especially if it is important that this works across multiple devices.

Good luck, and let us know how you do. Sounds like a fun little project.

Thanks for the thorough advice! My knowledge on writing with flash memory is limited so starting small and building up will definitely be the way to go. I will definitely give some updates in the future once I start getting everything figured out!

 

[gregolive]

"do you think the serial monitor is able to display a signal at this frequency?"

Haha -- no I really do not know why I did not think this through, the baudrate isn't even high enough!

No problem! Could have fooled me haha