POCtec / Yuwell ct3 anytime CGM app.

[GaryJurgens]

Hi guys
Do you know if the Yuwell ct3 Anytime CGM would be available. I believe it also goes by POCtech, it's really gaining Traction and is available in South Africa, and I believe Germany, as there is a Distributor in Duesseldorf.

It is EU Approved. The App is OK, you have a follow function and app. I have been using it since October 24 and very happy. The App is on play Store, I will post what I believe is the most recent Apk, below.

The app does give notifications, I tried connecting to companion app, and tried all the settings I could think of.

Especially in the interactivity settings. I downloaded the latest Xdrip+ stable release from jamorham today, 1 Jan 25. XDRIP is very special. I am an 20 year software dude, that will try to help as far as I can.

https://play.google.com/store/apps/details?id=com.yuwell.oversea&pcampaignid=web_share

All the best for the new year

Thanks G

[Navid200]

What is the link in your post pointing to?

[GaryJurgens]

Is this it? https://play.google.com/store/apps/details?id=com.yuwell.oversea&hl=en-US It doesn't say CT3 though.

Yes, it's because they also have a slightly more advanced/or previous version CGM called the CT10, but I have not seen it yet. This was Only Launched in South Africa I think in August of this year.

[Navid200]

I need a link to the Google Play store of the exact app you are using.
If the app is not available in the play store, tell us.

Attach the screenshot of the notification to your post in this thread.

[Navid200]

And edit your post and remove the link as stated already or I will have to delete this thread.

[GaryJurgens]

HI my Apologies, I was on my phone and forgot to press save, the link provided is the exact one i am using.

[Navid200]

Please show a screenshot of the notification.
Thanks

[GaryJurgens]

Hi, my apologies for the delay. The app does not broadcast notification values like other companion apps do, so that approach is out.

I installed the nRF Bluetooth snooper app from Nordic Semiconductor (available on the app store) and its associated logger app. After initiating a scan, within about 5 minutes, a device with a serial number appeared. In my case, it was the serial number of the rechargeable transmitter. When you set up the app for the first time, you either manually input this serial number or scan a QR code. It locked on with no problem, though there was a lot of Bluetooth "noise" from other devices (Bluetooth watch, laptop, headphones, and a Bluetooth LE CGM), all connected to my mid-range Galaxy A25 5G phone. Among the noise, the following stood out:

• A notify packet from the characteristic ID 00001001-1212-efde-1523-785feabcd123 consistently sent notifications with a stable encoding pattern and a value payload.

The device transmits a reading every 3 minutes, as stated in the manual, over the 14-day sensor lifespan. Below are Thursday, January 9th readings extracted from the logs:

1. Files provided:

   • 2_9_SN1740005690.csv: Two identical files, one delimited in Excel and one raw.
   • Log 2025-01-09 14_11_19.txt: Log file from the nRF Logger app in debug mode. It's messy but contains useful information after cleaning.

2. Interesting JSON Data:

   pocGlucose = PocGlucose{
       deviceId=9, 
       bytes=[7, -93, 1, 1, -100, 7, -99, 70, 55, 4, 28, -93], 
       glucoseId=455, 
       glucoseIndex=455, 
       BGCount=0, 
       BGICount=437
   }
   

pocGlucose stands for PocTech, the manufacturer.

2. roughly Every 3 Minutes you find a notification like this, - we know 3 min is the Transmission reading by reading the manual.
   Notification received from 00001001-1212-efde-1523-785feabcd123, value: (0x) 07-BE-01-01-92-07-94-46-3A-04-1C-94

3. I ran many more matching, Analytical AI is Awesome. (when i was university, our Professors made us do the Hex Decoding by had on paper.), the following was the results, so Let's analyze the pattern:

• First byte is consistently 0x07
• Second and third bytes seem to increment (BE, BF, etc.)
• The glucose values (pocGlucoseMG) are in the 270-280 range
• BGICount increments sequentially

Looking at the hex structure and the corresponding glucose values, it appears that:

• Bytes 5-7 might encode the glucose value
• Bytes 8-9 might relate to the BGICount
• The last few bytes (04-1C) appear to be consistent markers

I ran more tests, but I kept getting whole Numbers, for the supposed BG Reading, then I rememberd that its "American Units" I work in mmol, tracking in whole units, makes sense, because you cannot make a Decimal fit int a standard Byte (floating point, come into play here), with this i was able to take the mg/dl whole number and divide it by 18 to get mmol and the following appears.

`Time: 14:26:47
HEX: 07-B9-01-01-83-07-4A-46-4C-04-1C-48
Glucose: 276.0 mg/dL (15.336774 mmol/L)

Time: 14:29:47
HEX: 07-BF-01-01-8B-07-77-46-14-04-1C-4B
Glucose: 274.0 mg/dL (15.198206 mmol/L)

Time: 14:32:47
HEX: 07-C0-01-01-82-07-5B-45-56-04-1C-68
Glucose: 271.0 mg/dL (15.061797 mmol/L)

Time: 14:35:47
HEX: 07-C1-01-01-9E-07-65-46-04-04-1C-3E
Glucose: 272.0 mg/dL (15.106424 mmol/L)

Time: 14:38:47
HEX: 07-C2-01-01-90-07-5B-46-5E-04-1C-81
Glucose: 270.0 mg/dL (15.025781 mmol/L)`

Nicely 3 minuets Apart and corresponds nicely with my currently crap sugar control, because i have this "NovoVirus" that playing Havoc.

Looking at the Byte Patterns we can see the following.

Consistent pattern:

• Byte 1: 07 (static)
• Bytes 2-3: Increments (B9 → BF → C0 → C1 → C2)
• Bytes 4-5: Varies
• Bytes 6-8: Seems to correlate with glucose values
• Bytes 9-12: Includes consistent markers (04-1C)

Tracking glucose value changes:

• When glucose drops from 276 to 274: Change in bytes 6-8 from 4A-46-4C to 77-46-14
• When glucose drops from 274 to 271: Change in bytes 6-8 from 77-46-14 to 5B-45-56
• When glucose rises to 272: Change in bytes 6-8 from 5B-45-56 to 65-46-04

Ran more Readings and Conduced the following

From the Log file, we see two relevant characteristics:

• Main data characteristic: 00001001-1212-efde-1523-785feabcd123
• Unknown characteristic: f7bf3564-fb6d-4e53-88a4-5e37e0326063
• The glucose readings consistently come from notifications on 00001001-1212-efde-1523-785feabcd123 as suspected

Ran more to triple check the position of the bytes are consistent, and Concluded the Following.

• First byte is consistently 07
• Second byte increments sequentially
• The glucose value appears to be encoded in bytes 5-7 (positions 5,6,7 in the hex string)
• Last few bytes typically end with 04-1C followed by a checksum

Looking at larger value changes:

• When glucose jumps from 105 to 119 (14 mg/dL increase), significant changes in bytes 5-7

• When glucose rises from 119 to 133 (14 mg/dL increase), similar pattern of changes

I ran the a lot more Sniffer logs, since its consistent, and quite stable connection, because the rechargeable transmitter has decently sized good Mah capacity at 3.7v Battery, which is awesome, compared to other brands.

The following Conclusion is:
Pattern Confirmation:

• First byte always 07
• Second byte increments sequentially (76→77→78→79→7A...)
• Bytes 5-7 show consistent correlation with glucose values
• The pattern holds across different glucose ranges (70s to 270s mg/dL)

Value Encoding:

• Major changes in bytes 5-7 correspond to glucose value changes
• Looking at byte 6 specifically:
• Low glucose (70s-80s): Values around 01-02
• Mid glucose (100s-130s): Values around 02-03
• High glucose (270s): Values around 07

Consistency Check:

• Pattern remains consistent across:
• Different time periods
• Different glucose ranges
• Both stable and rapidly changing values
• The characteristic ID 00001001-1212-efde-1523-785feabcd123 consistently sends these notifications, and the pattern of encoding appears stable across all readings.

The Awesome thing is the App log, shows it much clearer and in mmol, in the app windows its self, than it exports it, They match up extremely, closely, which means that there is no Deviation or Correction math to worry about, because the more powerful and advanced chip this transmitter has (3.7v) allows you to do this. Means that its All done on the transmitter its self, before broadcast.

to Summarize this whole exercise, we can very confidently say the following:

Characteristic that sends glucose data:

• ID: 00001001-1212-efde-1523-785feabcd123
• Sends notifications every ~3 minutes

Observed values match manufacturer's app, confirming:

• mg/dL values are directly readable
• No complex decoding needed
• Values update reliably every 3 minutes

The Packet Structure (12 bytes): and looks like the following.

This means for real-time glucose monitoring, we need to:

• Connect to the device
• Subscribe to notifications from characteristic 00001001-1212-efde-1523-785feabcd123
• Parse bytes 5-7 for glucose values
• Values received will match the manufacturer's app readings

We have a Damn Stable and Reliable Signal Collector Mode, and no app work around.

I might be Mistaken but , does Xdrip, have a very advanced deep setting already, i would be able to do this on, at least to test.

Can Someone help with or guide me to Step 2, get Xdrip to detect it and use it, it will be much appreciated.

While there App is good, as a Programmer myself, Its Not Xdrip Or No Where Close. but when the Transmitter Costs R500 ZAR ~ $26 USD, for 2 years of use, and a Sensor R 650 ZAR for 14 days ~$ 33 USD, it makes a difference, for a Lot of people. it does upload to Glooko - but meh.

I have been using it since it became available, and its Defiantly a Damn good unit, My Insurance covers them all, so i have Tired them all and this unit is the one that has Given me the Least Trouble, in fact, I only has 1 Sensor failed and was me not following instructions, or the Video with the Instructions.

I do think we need to Support these Because PochTech and Yuwell (or what ever structure, the Chinese do) is a very Large Company that makes things from Ventilators to Cpaps. but from what i can find directory is the the Following.

IT Is EC APPROVED 2797 and is Available in Germany via a Company called ProLinx GMBH in Dusseldorf.

Its very interesting who the Founder and Director is.
Director, founder and Team

The History is Not bad either and they where Acquired by YuWell
History

My CT3 User Manual and technical manual

Ct3 User Manual

My Unit, Won the Red dot Design Award, in 2024

Ascecsia Diabetes Partnership

Advertising Videos
9_SN1740005690.csv
Log 2025-01-09 14_11_19.txt

thank you and Good night From Cape Town , South Africa. 0 well morning its 5am, i need an hour of sleep :)

9_SN1740005690.csv
Log 2025-01-09 14_11_19.txt

[GaryJurgens]

@Navid200 @jamorham HI, based on above, i believe i can add this transmitter to the Collection Transmitters , directly. i have looked at the repo and have a good idea on how to add this transmitter to to the project, I really what to use Xdrip, this transmitter is great, but the app, is lacking. Even my endo to day, was saying It's just not there, he has 4 Patients already on this Transmitter, because its very good.

So at least for them and myself, i could do this. its actually very popular in china, Europe, Mostly Eastern , but IS EU approved and distributed out of a Company in Düsseldorf, Germany.

I dont believe they are after the US market, as Quickly , because there are plenty of other Diabetics around the world, especially the Asia countries.

I belive that Dexcom and Libre have taken there concentration at the moment to the Stella and the libre one, as its a big market for them, even though they are basically repainted , rebranded, and FDA reclassified versions of the G7 and Libre.

Likewise, I would love to do a Community Fork, with the intent to contribute back to the Community once its working and tested.

[Navid200]

You can go ahead and open a PR. Thanks

You can contact me at the following:

xDrip dot Navid at gmail dot come