Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0v - 1v] range don't acts as v/oct #37

Open
j3o3n3 opened this issue Jan 30, 2025 · 10 comments
Open

[0v - 1v] range don't acts as v/oct #37

j3o3n3 opened this issue Jan 30, 2025 · 10 comments

Comments

@j3o3n3
Copy link

j3o3n3 commented Jan 30, 2025

Today with Xavi we detected strange behaviour in range betwen 0v to 1v.

Is expected than if we tune one note sending 0v to v/oct input, for example C1, then when we send 1v we will obtain a C2.

Instead of this we obtained A1. It's 3 semitones down than the C2 was expected.

It only happens in the 0v to 1v range, it means if you send 2v, in this case you get one octave. According the example, if 1v provides A1, 2v provides A2, 3v A3.... and so on.

Proposal to reproduce this possible issue:

  • Connect Oneiroi output into a tunner.
  • Without connecting nothing to v/oct input, use sine wave without any knid of effect.
  • Tune one note (for example a C) using the pitch pot.
  • Then add 1v on v/oct input.
  • If our suspicions are correct, you'll get one A on tunner.

Exploring this behaviour we found another interesting fact. It seems Oneiroi don't recognise the first voltage values: 0v, 1/12v, 2/12v, 3/12v are not recognised in v/oct input. In theory, 1/12v corresponds to one semitone, so here are 'the 3 lost semitones'.
Example using Voltio module:

  • Connect Oneiroi output into a tunner.
  • Without connecting nothing to v/oct input, use sine wave without any knid of effect.
  • Tune one note (for example a C) using the pitch pot.
  • Connect Voltio output to v/oct Oneiroi's input.
  • Make sure Voltio module is not adding any voltage. Top pot at 0v, bottom pot at C position.
  • Now apply one semitone increment on Voltio (C#), observe note don't change.
  • Now try two semitones, put bottom pot to D position. Then D#. Don't changes too.
  • If you go to E position, now Oneiroi will up a semitone the note you are listening.

I hope it helps.
Thanks

@athousanddetails
Copy link

Yes, I confirm this too.

Please fix it :D ?

@hemmer
Copy link
Collaborator

hemmer commented Feb 13, 2025

I ran into this with the VCV version, not saying this is the appropriate fix but I didn't understand why this line was present (it looks to just wipe out a few semitones): 346dd6e?diff=split#diff-537f7b72e5c4648c6a3a44843dabd1d006597c038ee6659c671d7bebadc2515bR1385

@xustafu
Copy link

xustafu commented Feb 14, 2025

Reproduced at home!
@hirnlego can you reproduce this in your unit?

@hirnlego
Copy link
Collaborator

@xustafu I'll have a look later. From what I remember, there was an issue with getting precise readings in the lower end of the v/oct CV range and thus the line pointed out by @hemmer.

@hirnlego
Copy link
Collaborator

So, the issue of the three semitones was raised by me when working on the calibration, but then we kinda forgot to follow through: https://github.com/Befaco/Oneiroi_dev/issues/17#issuecomment-2068071417.
Eventually, I added the patch above to ensure that at least those three semitones were read as 0 and not as some random offset.
It's not a patch issue, and honestly I don't think it's a firmware issue either. May be something at a lower level, even hardware. In any case I'm willing to brainstorm.

@Diegoterrores
Copy link
Collaborator

I've been testing the module's V/Oct input block and wanted to determine how the voltage corresponding to the first semitones affects the microcontroller's pin.
It appears that the voltage of these initial notes is not clipped on the hardware side, allowing this information to reach the microcontroller (at leats the pin of it).
It would be beneficial to monitor the voltages in relation to the ADC values to check for any "dead zone" on the ADC.

Can someone provide information on what the first semitones/millivolts look like on the ADC?

Also, Does the calibration routine take 0 volts into account to determine the real zero point during calibration?

@hirnlego
Copy link
Collaborator

@Diegoterrores I'll try and make a few tests tomorrow.

@hirnlego
Copy link
Collaborator

@Diegoterrores I'm still having the same results as in the other issue/repo (see above).

These are the ADC readings, inside the firmware BEFORE any conversion or calibration (using VOLTIO):

0/12v (C0) -> 4095
1/12v (C#0) -> 4095
2/12v (D0) -> 4095
3/12v (D#0) -> ~4070
4/12v (E0) -> ~4035
...
10v (C10) -> ~15
10v + 1/12v (C#10) -> 0

As you see, I receive the same value for the first three voltages, so these semitones are lost.

This is a multiplexed CV, don't know it's of any relevance here.

@antisvin
Copy link

Roberto, you can see that first semitones should be going above 4095, but this is not possible as we expect to have only 12 bits (so 2**12 - 1 = 4095 is maximum possible value). The actual ADC is 16 bit, but it later gets truncated and this doesn't change anything as its just about having less noise in processed signal.

I imagine we have an opamp with negative feedback befor ADC, scaling and inverting the signal from 0..10V to 3.3V..0, but it ends up generating something like 3.4V from 0. So it could only be corrected in hardware, most likely as finetuning for VREF voltage.

@Diegoterrores
Copy link
Collaborator

Diegoterrores commented Mar 5, 2025

To achieve perfect tuning, ensure you input a voltage other than zero before tuning. With proper calibration, tracking across several octaves is quite accurate, though the first semitones are be truncated, as noted by @hirnlego in their ADC readings.

For example, if you are sequencing Oneiroi using the V/OCT input, connect your sequencer to it and send 1 volt (which corresponds to the C1 note) into the Oneiroi V/OCT IN. Tune Oneiroi to C (or your preferred note) and adjust the octave accordingly to compensate for the extra volt. Everything should be in tune now!

As @antisvin mentioned, fine-tuning this will require a hardware revision and the removal of the code lines that @hemmer pointed out at the beginning of the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants