Calibration Rejected: Unknown code:12

[old-square-eyes]

Started seeing "Calibration Rejected: Unknown code:12" when trying to calibrate my Anubis. Both in factory calibration mode and no code mode.

Happened the first time when calibrating when it was way off. Thought it might be the death spiral (where calibrating too far puts it into an error state).

But I reset the TX with the reset tool, and started nocode. It took the first calibration. But 24hrs later when it requested a new one it got the error 12 again, and I haven't been able to calibrate it since.

Sensor is 3 days old. Some noise but not crazy bad. Nothing to suggest the sensor is failing.

Could it be a faulty transmitter?

I was able to fall back the Anubis to xDrip algo (non Native) by enabling Engineering Mode. It's accurate now.
Any reason that would be a bad idea? (am experienced in xDrip algo from G5 days)

[old-square-eyes]

Can't find much on this error online. Just:
#405
and...
https://forum.fudiabetes.org/t/new-sensor-wont-accept-any-calibration-unknown-code-12/8669/10

[Navid200]

G6 is an evolution of G5.
We had no choice but to calibrate a G5 because a blood glucose meter was still better than G5.

G6 is different. The variation of the sensor due to the impact of the immune system, on the sensor filament, is already accounted for by the G6 calibration code. The sensor to sensor variation due to production line spread is also accounted for in the G6 calibration code.
That's why it is a bad idea to use a G6 in non-native mode. Because it will completely disable the G6 factory calibration.
Using a G6 in non-native mode is like removing the engine from a motorcycle and using it as a bicycle. Yes, you can do that. But, why would you want to?

G6 is not perfect. Neither is a blood glucose meter. But, they are both better than a calibrated G5.
The difference between G6 and your blood glucose meter is due to the combination of the nonidealities of the two. Calibrating G6 with respect to a blood glucose meter is not meant to be done the way we did it with a G5.

You should only attempt to calibrate a G6 if you are certain something is wrong. And I don't mean relying on your blood glucose meter as a point of reference. Only if you have symptoms that G6 disagrees with, should you calibrate.

Regardless, if you attempt to calibrate to a value resulting in a delta greater than 20% of the current reading, it is my experience that you will get a calibration error.
When I have had to calibrate, limiting it to 20% of the reading has allowed me to consistently succeed as explained here:
https://navid200.github.io/xDrip/docs/Calibrate-G6.html

[old-square-eyes]

Appreciating the background, and long response, so thank you for your time. I'd like to focus on a couple of points.

G6 is never accurate enough for me. I have tried many times to wait out the inaccuracies. But I think in my case it's physiological. ~80% of sensors read high for a couple of days. Bad news when looping. Other times the slope is way off. So I might have a lock in-range, but as I approach towards 10 mmol/L I'm way off at around 7mmol/L. This causes over corrections.

But none of this matters because usually I can give it a nudge by calibrating, and then it's accurate enough for me. But almost never can I "just leave it".

Almost never do I use nocode. I have only been using nocode because of this error code 12 - where get into my usual state of being off and trying to nudge it back. But unlike before, this sensor/tx combination will not allow me to calibrate. The 20% thing does not apply. I have tried smaller increments. It just refuses to calibrate. And I have started clean with a reset Anubis, and still had issues. So it's not that I'm peppering it with calibrations causing to get it in a bad way.

So the issue at hand is the error code 12, and perhaps this specific transmitter/sensor. I am fortunate enough to have another Anubis. So I'll continue to test once this sensor have given up the ghost.

[Navid200]

When I switched from G5 to G6, I swore for a few months that G6 measured too high consistently. Eventually, after comparing to lab results, I realized that it was my blood glucose meter that measured 0.8mmol/L too low consistently.

There are others who are not happy trusting G6. I only share with them my experiences. But, it would be wrong of me to claim they are wrong.
I do mention that I myself behaved differently when I first switched to G6 because I was 100% sure calibration was a necessity. I am the same person using the same technology today. But, today, I feel differently.
I wish someone told me then about other perspectives I could have considered. I wish I had trusted G6 sooner. Until I did, I argued that something was wrong with it.

I don't believe for a second that G6 is perfect. There are expected distortions.
If I am high, I need to lower my glucose. If it tells me that I am higher than I really am, as long as I am high, I don't care. I need to lower it anyway.
If I am low, I need to raise it. If it tells me that I am lower than I really am, I don't care. I still am going to behave the same way, eat or drink something.

On the other hand, if I am 5.5 (in range) flat and it tells me I am 4.5, that is unacceptable. That would be a serious problem.

It is possible that I am lucky that do not experience unexpected errors with G6.
I am curious if your other transmitter behaves any differently.

[old-square-eyes]

I will certainly report back. But having been on G6 for a couple of years, and one of the first Anubis users (over a year). I have absolutely, successfully, given it the gentle nudge when required (frequently, out of necessity... though as mentioned I do try not to). I also use 2-3 test strips, and flat trend to give it the best possible calibration - appreciating the glucometer may itself be out consistently too. But this new error code is a deviation from BAU for me. Something has changed and it persists through an Anubis reset. Using nocode is not normal practice for me but out of desperation trying to get a functioning setup through the course of a busy work week. The non native (be it a motorbike without an engine) is also an effective stop gap solution. Though, also not ideal. But I did find it suitably accurate (much like a G5).

[old-square-eyes]

There has been an interesting development. My sensor started coming to an end. Keeping in line with the overlap technique, I switched collection to a second xDrip variant1 instance, and collection there commenced successfuly. I had been on non native previously for the fore mentioned reasons. But variant1 xDrip kicked off in Native mode as that was the settings from the previous. Knowing that I may need to calibrate (waiting for the new sensor to soak in my main xDrip), I did so. And... This time, for the first time in many attempts, I got no error 12 and the calibration was accepted.

So... Either the transition to the new xDrip in itself released the bug/calibration lock, or the xDrip versions were significantly different (the first one having a defect), or (unlikely) the sheer amount of time I was running non native caused my transmitter to suddenly be able to natively take a calibration.

Note, throughout the use of non native over the last week, all of the calibrations continued to result in error 12.

xDrip: 2023.03.06
variant1: 2023.01.12

[old-square-eyes]

Also adding, calibrating the new sensor on my main xDrip also worked fine (Native)

[Knightprozac]

I experienced something very similar running anubis.

Reset tool was also unsuccessful for me. What did work for me was xdrip -> system status -> forget device

I did this at the start of replacing sensor but previous new sensors had not resolved my issue.

I also found significant variance on xdrip readings prior to calibration. I'm not certain how accurate my blood strips are but definitely more accurate than g6 for me.

[old-square-eyes]

The debate about whether you should calibrate is only relevant here if certain calibration behaviours should exacerbate this issue. However, it's clear you can get in a very bad state where it is difficult to recover (even through resets). I'd like ot focus the discussion on that.

[Navid200]

xDrip has no role to play in calibrating G6 other than submitting it to the transmitter.
It is the transmitter that may not like your calibration and go silent for hours. There is nothing we can do to xDrip to change that behavior of the transmitter.
In other words, even if you use the Dexcom app, you could cause the transmitter to reject a calibration and go silent.

For a while after the release of FireFly G6, xDrip had some messages that were confusing. For example, there was no clear way to submit a calibration. Or after submitting a calibration, there would be messages stating that the calibration had been rejected.
We have addressed all such issues.
If you believe there is still an xDrip behavior, with respect to calibrating a G6, that is confusing, please let me know.

However, please note that I am talking about an xDrip behavior.
If for example, xDrip does not show readings because the transmitter is not providing any, that's not really an xDrip behavior that is causing the problem.

If you don't like the log messages like unknown code 12, there is not much we can do about that either. You may not see anything meaningful in that case if you were using the Dexcom app either as far as I know.

If you can use a different device, you can run the Dexcom app on it. You can use what I have described here to change the slot number xDrip uses: https://navid200.github.io/xDrip/docs/G6_slot.html
Then, you could have both xDrip and Dexcom app attached to the same transmitter.
Now if you ever get the unknown calibration code, please tell me what you see on the Dexcom app.

[old-square-eyes]

To be clear I didn't presuppose this was an xDrip issue (though I had hoped there might be some recourse through xDrip - or community knowledge). I'm simply opening the discussion for people to get info and share experiences. Good to know about the slots.