10mv offset on all OCP outputs

[sonic2ndtwelve]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[patrickdowling]

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

[sonic2ndtwelve]

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]

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

[mdroberts1243]

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?