10mv offset on all OCP outputs about o_c HOT 18 OPEN

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.

from o_c.

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.

from o_c.

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.

from o_c.

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.

from o_c.

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.

from o_c.

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!

from o_c.

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.

from o_c.

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"...

from o_c.

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).

from o_c.

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.

from o_c.

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

from o_c.

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

from o_c.

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.

from o_c.

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

from o_c.

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?

from o_c.

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).

from o_c.

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.

from o_c.

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?

from o_c.