FV-1 pin lifts floor of signal from uC (I think?). Need help understanding

[mark2]

So I have something like the following. And if this simplified version doesn't explain the problem, then I can sketch out a more complete picture.



An FV-1 and ATTiny share ground, but have their own separate regulators.

The attiny outputs a square wave, but its low value is about 700mV:


When I disconnect it from the FV-1, it drops back down to 0V.


Anything obvious I'm misunderstanding that would explain what's happening? I expect the low value to always be around 0V.

Edit: and the high value of the signal isn't moving. Only the gnd.

[PRR]

> The attiny outputs . . . . . When I disconnect it from the FV-1,....

Disconnect what? The ATTiny? The 10k?

Why would it go to ZERO? Only because the internal transistor has gone to zero Ohms. It can't. It may go to milliVolts on its own, but with tiny transistors it may not go way low with 10k pulling up.

I'm missing 3 fingers this evening and can't Google or draw. Sketch the whole plan, both ways, and link the datasheets.

[mark2]

Sorry for not being clearer, and thanks for taking a look.

The first scope pic shows the signal at the "PROBE" net in the drawing.  The second scope pic shows the signal when R6 is removed.

i.e. the attiny in isolation is outputting a square wave between roughly 0V and 3V3. This is what I want the FV-1 to read.

When R6 is connected, however, the square wave goes between roughly 0.7V and 3V3. This is the undesirable behavior I'm trying to understand.

Datasheets: attiny85, FV-1.

I'll get to work on a complete schematic, but what's missing is very close to the FV-1 datasheet.

[mark2]

Here's a complete schematic. I removed one resistor and replaced it with a switch to more clearly illustrate.

When the U3 switch near the bottom is closed, the first scope image is the result. When it's open, the wave is its full intended 0V to 3V3.



(edit: replaced image w/ higher res)

[mark2]

And in case anyone ever comes up with similar symptoms in the future, it was a boneheaded mistake in the AVR code: I never set its pin as an output.

So while it was outputting the high/low values just fine it wasn't able to drive any sort of load.

[ElectricDruid]

And in case anyone ever comes up with similar symptoms in the future, it was a boneheaded mistake in the AVR code: I never set its pin as an output.

So while it was outputting the high/low values just fine it wasn't able to drive any sort of load.

Gagh! I feel for you, having done similar things myself about a million times....

I once spent ages chasing a bug in my code that turned out to be a dead pin on the chip I was using - inadvertently fried at some earlier point. And I wasted days trying to find out why the setup on that pin wasn't working. On another occasion, I spent a week trying to work out why my code wasn't working before I thought to check for datasheet errata, and subsequently discovered that there was a bug in the *silicon* that meant that the whole thing kept screwing up in all kinds of interesting and unpredictable ways!! At least that one wasn't my fault!!

The good news is you found the bug, so let's focus on that!

[mark2]

Wow those sound like some serious headaches. At least they weren't really your fault.  Not sure if that makes it feel worse or better when you get through to the other side.

[potul]

I was tempted to suggest "did you set your pin as output?" at first but thought "nah, he's seeing the square wave without load, it must be ok". I guess I was wrong.

Now that we've seen your project, we have curiosity on what you are trying to achieve. Are you feeding a square wave into the FV-1 throught a POT input? Or are you going to use PWM to control the pot input?

[mark2]

This is for a tap tempo, feeding the tempo into a pot input.

I'm adapting Slacker's code of course. Still have some bugs to work out because I get a weird fluttering speed up between the beats.

I'll also be doing PWM on the other two pots, though. Those will probably pass through a LPF.

[potul]

I built a similar circuit last year. If you are trying to send a pulse train from the atmega to the fv-1 to set the tempo (that's what I did in my project), let me give you a couple of tips:

-Apply the "fastpot" filtering to the pot input. I see you already contacted via pm for this... so you are good to go
-You can simplify the FV1 code, as you don't need debouncing
-When I implemented I realized there was way too much delay in setting the tempo, because I was tapping into the attiny, then sending the tempo to the fv1. So double the time. What I did to minimize this is to scale down the pulse train, and modify the code in the FV1 accordingly. This way, let's say I want to set the tempo to 500ms, I send a pulse train of period 125 ms instead.
If I recall correctly I did some other changes into the code to improve reliability at small delays.

Mat

[Sweetalk]

This is for a tap tempo, feeding the tempo into a pot input.

I'm adapting Slacker's code of course. Still have some bugs to work out because I get a weird fluttering speed up between the beats.

I'll also be doing PWM on the other two pots, though. Those will probably pass through a LPF.

Why don't do the PWM in all the pots and evaluate the tempo in the attiny or it has only 2 pwm outputs?. I've done it that way and works really good.

To add to @potul says, you can open up a window to send the tap tempo signal and not having a square wave present all the time. When detects a new setting of the tempo, starts the counter, outputs the square wave (make shure you have enough periods of the signal) and then shut it down, just like a normal tap tempo would do. Helped me to minimize the noise.

[mark2]

-Apply the "fastpot" filtering to the pot input. I see you already contacted via pm for this... so you are good to go
-You can simplify the FV1 code, as you don't need debouncing
-When I implemented I realized there was way too much delay in setting the tempo, because I was tapping into the attiny, then sending the tempo to the fv1. So double the time. What I did to minimize this is to scale down the pulse train, and modify the code in the FV1 accordingly. This way, let's say I want to set the tempo to 500ms, I send a pulse train of period 125 ms instead.
If I recall correctly I did some other changes into the code to improve reliability at small delays.

Great tips, thanks. I'm definitely following all those.

Once I get it working, and especially if I want more instructions, I'll probably give this stripped down version a closer look: http://www.spinsemi.com/forum/viewtopic.php?p=3884#p3884

Why don't do the PWM in all the pots and evaluate the tempo in the attiny or it has only 2 pwm outputs?. I've done it that way and works really good.

I'm not strictly opposed to that, but I think doing a square pulse that reflects precisely the tempo (or a subdivision of it as Mat recommends) is dead-simple to work with whereas a PWM to set the tempo needs to be calibrated or have some sort of lookup table.

And good idea to only send a handful of pulses. Thanks.

[potul]

I tried the pwm-into-POT approach and could not get it working accurately. Not sure if this was an issue with the circuit design, filtering or something else, but I had issues keeping a steady value sent via PWM to the FV1. And in this case, you really need a continuous consistent value. I decided to use a pulse with a width proportional to the desired timing, and use a modified tap tempo code in the FV1. This is quite accurate.

[Sweetalk]

I haven't got any stability issues with the pwm-to-POT really, attached directly (well, a level shifter to lower from 5v to 3v3 where used).

[GuitarPhil]

I tried the pwm-into-POT approach and could not get it working accurately. Not sure if this was an issue with the circuit design, filtering or something else, but I had issues keeping a steady value sent via PWM to the FV1. And in this case, you really need a continuous consistent value. I decided to use a pulse with a width proportional to the desired timing, and use a modified tap tempo code in the FV1. This is quite accurate.

You need good low pass filtering between the uC PWM output and the FV-1 pot input.

Phil.

[potul]

You need good low pass filtering between the uC PWM output and the FV-1 pot input.

Phil.

of course. Already did that. The issue was that voltage didn't seem to be stable, and this was very audible due to the delay time changing. As I said, problably it was something to be improved in the filtering, or maybe something else was influencing the circuit. Powering properly the AVR is also something to consider to avoid voltage fluctuations.

On the other side, I decided that instead of converting a time into a voltage, to then convert it to a time again in tne FV1, I would stay working only with time. So my AVR sends a square pulse to the FV1 with a width that is proportional to the delay time.