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

10mv offset on all OCP outputs #103

Open
sonic2ndtwelve opened this issue Jul 23, 2020 · 18 comments
Open

10mv offset on all OCP outputs #103

sonic2ndtwelve opened this issue Jul 23, 2020 · 18 comments

Comments

@sonic2ndtwelve
Copy link

Hi, I built the OCP module and it all works ok. It was calibrated using a 51/2 digit Keithley 2000 multimeter and all went OK. But, when I measure the voltages on the outputs (using all the Apps and Voltages App), they all seem to be around 10mv out/high, as if there is an offset being applied. Obviously, 10mv error is quite a lot when the module is capable of being calibrated to 0.1mv.

I’ve contacted Shay from Plum and he has checked this and found the same thing, putting it down to a bug in the firmware (1.3.6). He has asked me to also submit it here so that it can be fixed in the next release. Thanks. SJ.

@patrickdowling
Copy link
Collaborator

Did Shay specify if it's an issue just with OCP, or in general with 1.3.6 (i.e. on stock hardware, that's gone unnoticed)?

If there's something to be fixed in the OCP-specific code, it'd be much easier, faster, and nicer if he'd submit it directly. It's kind of his responsibility since he's the one building/releasing the firmware versions for the hardware variants anyway (unless there's some agreement I'm unaware of?). That's the second such issue and it's catching users in the middle.

@jmsiener
Copy link

I’ve got 4 O_C’s - 2 OG and 2 micro - and none of them have any issue with offset whatsoever. The addition of the attenuverters and possible offset options of the OCP make this module way more unique than the micro clones which are just scaled down modules with an extra teensy reset circuit. OCP strikes me more like a monsoon or supercell which I believe have their own modified firmwares. I wouldn’t expect MI to support all of these different Clouds iterations; similar situation here.

@patrickdowling
Copy link
Collaborator

Ok, thanks for the sanity check on regular hardware. I mean it's not inconceivable that it's been there all along, but someone should have noticed :)

Admittedly it's kind of a grey area because (some of?) the necessary changes were merged into this repository with #ifdefs. While it can be arranged, that doesn't (IMO) imply automatic fixing of any hardware-specific issues though. I'll try and find out what the expectations were, since I don't really think it should be the end user's worry either.

@sonic2ndtwelve
Copy link
Author

Shay didn’t mention it was a problem in O-c firmware generally but did mention that it could be a “bug in the VOR script” (what ever that means) leading me to believe that he thinks it is An OCP specific issue. I’ve just done yet another calibration on it and the error is there, differing, over all three of the VOR modes so he could be right.

@patrickdowling
Copy link
Collaborator

I see. Honestly I haven't looked too closely at the specifics of the offsettery beyond that it's provided by the Teensy's internal DAC. So that might not have the same specs as the rest.

@timchurches
Copy link
Collaborator

Plum Audio needs to provide some instances of its custom hardware to the authors of the firmware. Obviously it is impossible to develop and test firmware updates to accomodate such custom hardware without access to examples of that hardware!

@sonic2ndtwelve
Copy link
Author

I'm no expert but I'm surprised that they haven't. It must be impossible to test firmware without the custom hardware but Shay has said that he is going to pass it on the firmware development team to sort in the next release and hopefully this will be available soon. I've been playing around with my OCP for hours now and it seems to be a serious calibration issue, probably caused by lack of testing before release. All of the outputs (A-D) are showing 2mv - 30mv errors, over all of the VOR settings so its the VOR stuff that must be causing the problems - unless I'm doing something wrong of course. How its not been noticed before is amazing and this module kit was not cheap, costing me £175. For that sort of money I would expect it to work. With these errors, anything pitch related is going to be junk. Perhaps I should just get an OG o_C instead.

@patrickdowling
Copy link
Collaborator

Yeah, for implementation access to hardware is somewhat optional, but it has to be tested at some point :)

The "firmware development team" has always been a somewhat loose collaboration and not everyone was actually involved with the VOR features, it's not clearly defined who should be maintaining it, nor when/whether there would be a "next release". By default I still think it's primarily Shay's responsibility but we'll have to hash that out separately.

People have been using totally uncalibrated modules, or abused the calibration to work around build errors, so not much surprises me in terms of "things not being noticed"...

@sonic2ndtwelve
Copy link
Author

Indeed, it has to be tested at some point and it seems that the end user is the one testing it in this instance. If I had bought the PCB and panel and sourced the parts myself and it didn't work properly that would be my responsibility. But when I buy a kit like this, and for £175, I do expect the firmware to be tested by the designer. As I say, perhaps I should just get an OG o_C instead from Pusherman (if I can find a panel here in the UK).

@patrickdowling
Copy link
Collaborator

Yes, that is frustrating. We don't really have any control over the market though...
So after someone posted some hints on MW it smells like the offset stems from the the VOR calibration method, rather than the apps. Apparently the internal DAC has a long settling time so you get a timing-dependent value in one place and a (hopefully) stable one in the other. Should be fixable but yeah, it seems like that wasn't really tested.

@sonic2ndtwelve
Copy link
Author

Do you have the MW thread available? I can't seem to find it. I would be interested to read it.

@patrickdowling
Copy link
Collaborator

See here
After coffee an alternative explanation might also be "something" in the additional circuitry but the effect will be the same.

@sonic2ndtwelve
Copy link
Author

Hi Patrick, I hope all is good with you. I was wondering if there has been anymore progress on the O_cP calibration issue. I notice that Plum are planning on selling pre-built and calibrated modules so does this mean that the issue has been solved? Thanks.

@patrickdowling
Copy link
Collaborator

Hey,
sorry, as far as I know there's no systematic fix yet.

@mdroberts1243
Copy link

I just built my OCP and I found a similar issue... about 12mV offset on all reference levels in my case. Is there a workaround for this?

@mdroberts1243
Copy link

I just built my OCP and I found a similar issue... about 12mV offset on all reference levels in my case. Is there a workaround for this?

Further to the above, I tried looking at the offset while cycling through the VOR settings. At 0V-10V VOR I saw the 12mV mentioned (offset from 0.000V). At -3V to 7V setting I saw 24mV offset on the -3.000V expected. And at -5V to +5V VOR setting I saw 15mV offset from the -5.000 expected (so -4.985V).

@odourboy
Copy link

I recently completed an OCP module and after careful calibration, I am also observing a voltage offset on the output which appears to be a fixed amount for a specific VOR setting (about +6 mV for 0..10V) but varying depending on the VOR as much as 28 vM.

@patrickdowling
Copy link
Collaborator

I know it's a bit unsatisfactory, but I can only echo what I've said before -- you should be taking it up with Plum and they should be organising a fix. My suggestion was that they start by setting up their own branch to maintain their hardware specific firmware (it's not just the offset that's broken with VOR) but it doesn't look like that's happened?

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

6 participants