@ps2 observed that when launching the app from the debugger, centralManager:willRestoreState: is not invoked. This might also be true for other edge cases.

If we have autoconnectIDs that aren't currently in the device list when the central state is powered on, we should scan until we find them.

I have been playing around with my own IOS app using RileyLinkKit on my 522 pump. Everything I have tested works except for calling "setTempBasal" (in PumpOps.swift).

Is there a technical limitation that makes the 522 unable to accept tempBasal remotely?

Any "tricks" to getting make the setTempBasal function in RileyLinkKit work on a 522 pump?

Here's an example of what we recently discovered: bolus events are written after completion, and potentially out-of-order, for x22 pumps.

We still need to change this condition, I believe.

connection requests do not time out

Add more fields to deviceStatus upload to show current status of loop, such as suggested and enacted values, uploader battery, mmtune, etc...

An example of deviceStatus from openaps:
https://gist.github.com/ps2/af5b87c2b44a3657609160fc6f067231

Minimal info for openaps:
https://github.com/mddub/urchin-cgm/blob/master/test/js/test_data.js#L356-401

OpenAPS NS plugin:
https://github.com/nightscout/cgm-remote-monitor/blob/dev/lib/plugins/openaps.js

Pump Status plugin:
https://github.com/nightscout/cgm-remote-monitor/blob/dev/lib/plugins/pump.js

When the cgm page decoding algorithm detects that a page doesn't have a reliable sensor timestamp for forward looking offset, it needs to send a command to add a sensor timestamp to the glucose history page. Something in that code is incorrectly setting a new timestamp repeatedly in some circumstances. This causes glucose history pages to fill up more quickly and adds more page fetching that lessens battery life and reliability.

An example of the problem: https://diagcare.herokuapp.com/cgm_pages/DE0B68E27914E6EC8E211624D3C00CE6456164E8

The only timestamp that can serve as a reference for offsetting sensor readings is the SensorTimestamp (0x08). The other types, such as Cal BG for GH (0x0e) should not affect the sgv reading offsets or serve as a reference for sgv 5-minute offsets.

Additionally, the following events should be relatively timestamped in 5 minutes offsets:

• SensorDataLowEvent
• SensorWeakSignalGlucoseEvent
• GlucoseSensorDataGlucoseEvents
• Opcode 0x07? (if it represents a high bg)
• SensorCalGlucoseEvent

Other events like "DataEndGlucoseEvent" should not be included in incrementing the 5 minute offset.

And manage a signal to trigger serializing PumpState after model/timeZone changes.

5b0020540974100f5000784b500000300000000030965c05684bc0010030003000400020544974107b0400400a1410140b000a7a30752b74103f0f30754b7410c527ad5b7a067a0b7410265000b44b500000540000040054965c0830a3c068e9c00100540054000400067a4b74107b0500400c1410180a005b00356b0f74100f5000b44b500000200000000020965c0b54e4c03084d068cad00100200020000000356b4f74107b060040101410200e007b07004013141026100021002f6e131410030000003c1a6f3314107b0703401414102610000300030003347b1314100a3e25503414905b3e2750141410005100784b505800000000000058965c052019d0010058005800000027505414105b3e20581474100c5100784b505800280000580028965c085809c02021d0010028002800580020585474105b000a5d1474100f5000784b500000300000000030965c0b0c04c0740ec02026d001003000300080000a5d5474107b0800401514102a13000a4f0c5a3674103f090c5af67410c527ad0a5a005d3774103f0b005d577410c527ad331e095f171410081601095f17141007000002f014900000006e149005408e4f7a05000002f001342901bc3b007f0164005800000000060100000400000000000000003e3e00000000000000007b000941001510000e007b0100400115100208007b020040041510080c007b0300400615100c10000a5a0e722775103f0b0e72477510c527ad5b003577087510125000784b5000003c000000003c9601003c003c00000035774875107b0400400a1510140b000ae130722b75103f1c30722b7510c527ad5be1017a0b75103d5000b44b5028008400000400a8965c053cb7c05be1017b0b75103e5000b44b5028008800000000b0965c053cb8c05be1167b0b75103e5000b44b5028008800000000b0965c053cb8c07b0500400c1510180a000100880088000000167b4b75107b060040101510200e005b003a411075100f5000784b500000300000000030965c0888f6c03caad001003000300000003a415075101e010b6d1015107b07055e1315102610001f20055e1315105b002866131510295000784b500000880000000088965c0830dfc088cfd0010088008800000028665315107b0800401515102a13000abd00583575103f170058b57510c527ad5bbd05591515101e5000b4555010004000002c0040965c08886ec0304ad000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ec33

Keep track of last history fetch, and fetch older pages if needed. Also related; some records are mutable for a period of time, so we would want to refetch those as well. Perhaps we just keep track of the timestamp of the last non-mutable record.

From @loudnate on August 15, 2015 19:4

There are a lot of folks now with hardware that plan to talk to X22 pumps, which have about a dozen encoding differences across major packets. The most common one is when decoding insulin amounts, since the X22 and X23+ have different stroke sizes. However, there are other cases where bytes are in different offsets.

One approach that should work would be to create a family of PumpModel classes with an index by model string, and a family of Message classes to handle the decoding. MinimedPacket should continue to be agnostic to the intricacies of the message data and focus on RF encoding/decoding and validation.

Thoughts?

Copied from original issue: ps2/rileylink#20

There are two recurring stacktraces in crash logs related to Unbalanced call to dispatch_group_leave(), both in RileyLinkBLEDevice.

The stacktraces seem to indicate that the lines of code being executed at the time of the crashes are:

• https://github.com/ps2/rileylink_ios/blob/dev/RileyLinkBLEKit/RileyLinkBLEDevice.m#L147
• https://github.com/ps2/rileylink_ios/blob/dev/RileyLinkBLEKit/RileyLinkBLEDevice.m#L426

I'll attach the relevant stacktraces below.

Looking for the ability to use a MM CGM with an x22 pump, thus we will need to parse sensor data pages in rileylink

Related issue in Loop: LoopKit/Loop#100

A simple "is this the same packet as the last one we handled, and if so, drop it" should cut down on most of the duplicates.

LoopKit/Loop#29

I noticed my 522 pump (VER 2.1A) does not log any "BasalProfileStartPump" events. What pump models /firmwares generate this event? Any insight would be welcome.

From @loudnate on August 17, 2015 5:52

Should we keep track of paired MySentry IDs, then?

Copied from original issue: ps2/rileylink#23

...and don't bother asking the user

When the app is re-launched in the background, the central manager's state is restored with "connected" peripherals, before the CBCentralManagerState is powered on. Writing, reading, or subscribing to characteristics during that time results in the following warning:

Sep  4 18:36:04 Nates-iPhone-6 Naterade[4360] <Warning>: (Warn ) CoreBluetooth: API MISUSE: <CBCentralManager: 0x170269000> can only accept this command while in the powered on state

Sorry to feel so corporate, but as more folks start to use the app, some structure will help master be unbroken 😇

Thanks to @ecc1 for pointing this out!

https://github.com/ecc1/medtronic/blob/master/historyrecord.go

I haven't personally tested it, so it would be nice to get a unit test fixture.

These events are not yet handled in NS, but they are important for remote monitoring.

The web logs show it attempting to connect to GET //api/v1/experiments/test HTTP/1.1 when the nightscout url in 0.71 ends with a /, workaround is to remove it.

Figure out history event codes for restore settings and clear settings

Sensor Timestamp with type "gap" are marker for gaps in the sensor data and shouldn't be trusted for offsetting events that come after them. (The gap is between the sensor timestamp and the next reading)

When decoding at the beginning of a new page of cgm data, sensor events have no timestamp until a "reference" event occurs (such as a calibration). After the reference event, the cgm sensor events are processed with a timestamp. This results in gaps in the cgm data (and looping) between the time a new cgm page starts and the first reference event.

Edited: See comment below. Timestamp offsets should be applied in reverse chronological order, and there is a "page end" sensor timestamp at the end of each cgm page. Processing in forward chronological order causes gaps at sensor error points in time.

The history decoding has several switches based on the kind of pump being used. Occasionally we run into new records that break history decoding; since this could cause bigger problems, having an alert to warn the user that they're using a pump that the app hasn't been tested with is probably a good idea.

Would need to show the alert after we talk to the pump and figure out the model number.

Moved from Loop Issue tracker to rileylink_ios issue tracker:

Hey all,

Spoke to a few folks on Gitter and confirmed that it's happening to a few other people as well. Basically when Loop temporarily loses connectivity to RileyLink for a bit (guessing 15-20 mins), it will permanently stay disconnected, even if both are near each other and should be working. The only way to resolve the issue is a restart of the Loop app (note: a restart of RileyLink is NOT required).

You know you need to restart Loop because when you go into the Settings->RileyLink and try pressing on any of it's functions such as tuning the radio, getting pump model, or otherwise, absolutely nothing happens. It's completely frozen. To be clear, it's not Loop as a whole that's frozen as most things outside of the RileyLink screen still work, but it's the RL screen itself that's mostly frozen. Here's a video of me trying a number of RileyLink/pump functions in Loop after the freeze and as you can see nothing happens:
https://www.youtube.com/watch?v=oRMiyjWGvpc
(note that you can't actually see the "cursor" which is my finger depressing these functions, but I am and as you can see nothing happens)
-Also here's a gist of the crash report for when this happened grabbed from my iPhone: https://gist.github.com/ruess/dbad012d1f0dae85d6b754df5debdfdf

As noted above, after a simple restart of the app, things work again - however it's important to stress that it's not RileyLink which needs to be restarted, it's Loop.

While this isn't mission critical, it's happened once where things got disconnected somehow during the night and I awoke high because the 2 (Loop + RL) never connected again once they disconnected.

I'd like to see if there's a way to build in some sort of RileyLInk connection checker which gets triggered after more than 10 minutes of Red status. The way it would work is that if RileyLink wasn't detected, it would try restarting JUST the Loop functionality service that communicates with RL within the app in the hopes that it could potentially reconnect again without requiring the user to restart the app.

Any ideas where to start here? Basically having not dived into the code (and not being a huge coder myself), what kind of services within the app would be good candidates to try restarting (toggling on/off) in terms of RileyLink communication? Also, any ideas of where to place this feature? I'm guessing there may already be some activities that automatically take place when it turns to Red status in order to see what it can do to reconnect. Can someone point me to that stuff?

Let me know your thoughts and any ideas you might have about it.

=======================
@ps2
Collaborator
ps2 commented 2 days ago
Thanks, @ruess. This is an issue that's been around quite a while. Some people see it more frequently than others, it seems. I've only seen it rarely, and when the RL has been away from the phone for some time.

The more common diagnostic test is to look at the connection status. It will say 'Connecting...'.

One possible attempt to solve it that we've talked about is to see if resetting the core bluetooth central manager would fix it.

To test that theory, I would propose we do it in two steps. First we could make a version of the RL frameworks that has a new command to reset the central manager. Then user can manually try the command when they encounter the situation, and see if the problem resolves. If that does work, the second step would be to try to attempt to automatically detect the problem and automatically reset the central manager.

Here is where the central manager is initialized: https://github.com/ps2/rileylink_ios/blob/dev/RileyLinkBLEKit/RileyLinkBLEManager.m#L54
@ps2
Collaborator
ps2 commented 7 hours ago
This is also probably better tracked as an issue in the rileylink_ios repo
@ruess

=============================
ruess commented
Hey Pete,

Thanks for the detailed explanation and guidance! I think starting out with a button or switch of some sort that the user can try to restart things when this happens is a great idea.

Also, I'll copy over everything into the rileylink_ios repo and close this one out.

Thanks!

I have been hitting a crash like this: http://stackoverflow.com/questions/26656342/uiwebview-random-crash-at-uiviewanimationstate-release-message-sent-to-deallo
It looks like switching NightscoutWebView to WKWebView should help.

Nightscout deduplicates events by eventType and created_at in lib/server/treatments.js

NightscoutUploadKit uses TimeFormat which uses the ISO8601 formatter, which does the following:

formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssX"

That way if we try to write 2 events in the same second the second one overwrites the first.

I'd suggest changing the format at least for the treatments to capture milliseconds

formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ss.SSSSX"

or use the solution from this stackoverflow hint to capture microseconds

https://stackoverflow.com/questions/43123944/how-to-configure-dateformatter-to-capture-microseconds/43124982

Need to check firmware versions for ble113 and subg_rfspy in the app, and present dialog if they are out of date.

CalBGForPH is logged both when a BG value is entered manually into the pump and when receiving a BG value from the meter.

BgReceived is only logged when receiving a BG value from the meter.

Would like to see both in NS with a clear distinction between the events, or if I have to choose, I'd pick BgReceived. Right now it appears to only show CalBGForPH records. Need to figure out if there is something that can be changed in how it's uploaded, or if this is a change in NS.

Poll pump history, and extract treatments, meter bg, etc.

Review moving the code in MessageSendOperation -main back to -start. I had moved it when I encountered issues cancelling operations before they started, but that might not be the right fix.

While debugging my own code and comparing it to yours, I think I found a bug here:
https://github.com/ps2/rileylink_ios/blob/dev/MinimedKit/Messages/ReadSettingsCarelinkMessageBody.swift#L56

I may be misunderstanding your Swift code, but on a x22 model pump, the maxBolus value is in byte 6, not byte 7.
See https://github.com/bewest/decoding-carelink/blob/master/decocare/commands.py#L1274
versus https://github.com/bewest/decoding-carelink/blob/master/decocare/commands.py#L1310
(Ben's indices are all off by 1 compared to yours (and mine)).

Here is some test data:

model 522 pump

C0 15 0C 02 00 05 01 78 00 64 00 00 01 00 01 00 00 64 01 03 00 0F

should produce (among other values):

{
  "AutoOff": "12h0m0s",
  "InsulinAction": "3h0m0s",
  "InsulinConcentration": 100,
  "MaxBolus": 12,
  "MaxBasal": 2.5,
  "RfEnabled": true,
  "TempBasalType": "Absolute",
  "SelectedPattern": 0
}

model 523 pump

C0 19 0C 02 00 01 01 00 8C 00 50 00 00 00 00 00 00 64 01 03 00 14 00 64 00 00

{
  "AutoOff": "12h0m0s",
  "InsulinAction": "3h0m0s",
  "InsulinConcentration": 100,
  "MaxBolus": 14,
  "MaxBasal": 2,
  "RfEnabled": false,
  "TempBasalType": "Absolute",
  "SelectedPattern": 0
}

Play sounds on receiving alert packets.

They are markets as 14 bytes, but they actually have a length of 7 bytes and are followed by event 0x61(97)

We should be able to detect missing sgv data through the NS rest api, and if so, get the missing entries from pump history. Also, an individual mysentry update packet contains the previous sgv value, which should be used as well.

In JournalEntryMealMarkerPumpEvent.swift, bit 9 of the carb value is taken from the low bit of data[8], but it should be taken from the low bit of data[1].

For example, this is the record for a 10g carb entry: 40 00 93 27 10 10 10 0A 01
and this is the record for a 299g carb entry: 40 01 87 37 12 10 10 2B 01

I'm not sure yet what the 01 in data[8] means.

Maybe just a new textfield on the page after you click on the rileylink in the rileylink list.

Would be nice if we could get this info from the pump! Is there a way to dump paired meter ids?

0x06 events are sensor data low (sgv < 40) events and should be treated the same as glucose readings for the purposes of timestamp offsetting and incrementing. Currently, when a low event is decoded, it's treated as "unknown" and sgv readings after it in the page are incorrect by -5 minutes.

Can we add a method that does a no-op call to the Nightscout API using the provided credentials, to help users validate that it's working immediately after entering them?

@ps2 as someone who still hasn't setup Nightscout, I'm looking to you for guidance. The API endpoints I've seen seem to be read-only public; is that true for everybody? I'm hoping there's a way test both the URL and the secret.

Was trying to help someone diagnose connection errors, turns out the BLE device was constantly connecting and disconnecting. It would be nice to keep a ring buffer of things we're currently NSLog-ing and display them in a view controller with the option to share the contents.

@ps2 do you have any strong feelings about how this should behave? I was thinking of keeping the buffer on the RileyLinkKit side and surfacing a delegate method in BLEKit.

Need to be able to assign a custom name, to distinguish between multiple RileyLinks. This is already supported at the bluetooth level.

When fetching recent history from a Medtronic 722, UnknownEventType(93) is thrown if ChangeCarbRatioPattern event is in recent history.

Here are the CSV logs surrounding the problematic event, pulled from carelink:

83 5/29/2016 20:10:57 5/29/2016 20:10 0.925 Rate 0:30:00
ChangeTempBasal RATE=0.925,
DURATION=1800000, ACTION_REQUESTOR=rf_diagnostic 1.71E+10 54770231 312 Paradigm
722

84 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBGTargetRange
PATTERN_DATUM_ID=17077012918,
INDEX=0, AMOUNT_LOW=95, AMOUNT_HIGH=105, START_TIME=0 1.71E+10
54770231 301 Paradigm
722

85 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBolusWizardSetup
NEW_CONFIG_DATUM_ID=17077012929,
OLD_CONFIG_DATUM_ID=17077012920, ACTION_REQUESTOR=pump 1.71E+10
54770231 311 Paradigm
722

86 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBolusWizardSetupConfig
IS_SETUP_COMPLETE=true,
IS_BOLUS_WIZARD_ENABLED=true, CARB_UNITS=grams, BG_UNITS=mg dl,
CARB_RATIO_PATTERN_DATUM_ID=17077012921,
INSULIN_SENSITIVITY_PATTERN_DATUM_ID=17077012923,
BG_TARGET_RANGE_PATTERN_DATUM_ID=17077012927, INSULIN_ACTION_CURVE=240
1.71E+10 54770231 302 Paradigm 722

87 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBGTargetRange
PATTERN_DATUM_ID=17077012927,
INDEX=0, AMOUNT_LOW=95, AMOUNT_HIGH=105, START_TIME=0 1.71E+10
54770231 310 Paradigm
722

88 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBGTargetRangePattern
ORIGINAL_UNITS=mg
dl, SIZE=1 1.71E+10 54770231 309 Paradigm 722

89 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012923,
INDEX=2, AMOUNT=30, START_TIME=81000000 1.71E+10 54770231 308 Paradigm 722

90 5/29/2016 20:16:48 5/29/2016 20:16 ChangeCarbRatioPattern SIZE=1 1.71E+10
54770231 294 Paradigm 722

91 5/29/2016 20:16:48 5/29/2016 20:16 ChangeCarbRatio
PATTERN_DATUM_ID=17077012912,
INDEX=0, AMOUNT=8, UNITS=grams, START_TIME=0 1.71E+10 54770231 295 Paradigm
722

92 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivityPattern
ORIGINAL_UNITS=mg
dl, SIZE=3 1.71E+10 54770231 296 Paradigm 722

93 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012914,
INDEX=0, AMOUNT=30, START_TIME=0 1.71E+10 54770231 297 Paradigm 722

94 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012914,
INDEX=1, AMOUNT=20, START_TIME=36000000 1.71E+10 54770231 298 Paradigm 722

95 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012914,
INDEX=2, AMOUNT=30, START_TIME=59400000 1.71E+10 54770231 299 Paradigm 722

96 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBGTargetRangePattern
ORIGINAL_UNITS=mg
dl, SIZE=1 1.71E+10 54770231 300 Paradigm 722

97 5/29/2016 20:16:48 5/29/2016 20:16 ChangeBolusWizardSetupConfig
IS_SETUP_COMPLETE=true,
IS_BOLUS_WIZARD_ENABLED=true, CARB_UNITS=grams, BG_UNITS=mg dl,
CARB_RATIO_PATTERN_DATUM_ID=17077012912,
INSULIN_SENSITIVITY_PATTERN_DATUM_ID=17077012914,
BG_TARGET_RANGE_PATTERN_DATUM_ID=17077012918, INSULIN_ACTION_CURVE=240
1.71E+10 54770231 293 Paradigm 722

98 5/29/2016 20:16:48 5/29/2016 20:16 ChangeCarbRatioPattern SIZE=1 1.71E+10
54770231 303 Paradigm 722

99 5/29/2016 20:16:48 5/29/2016 20:16 ChangeCarbRatio
PATTERN_DATUM_ID=17077012921,
INDEX=0, AMOUNT=8, UNITS=grams, START_TIME=0 1.71E+10 54770231 304 Paradigm
722

100 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivityPattern
ORIGINAL_UNITS=mg
dl, SIZE=3 1.71E+10 54770231 305 Paradigm 722

101 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012923,
INDEX=0, AMOUNT=30, START_TIME=0 1.71E+10 54770231 306 Paradigm 722

102 5/29/2016 20:16:48 5/29/2016 20:16 ChangeInsulinSensitivity
PATTERN_DATUM_ID=17077012923,
INDEX=1, AMOUNT=20, START_TIME=36000000 1.71E+10 54770231 307 Paradigm 722

103 5/29/2016 20:21:00 5/29/2016 20:21 3.5 Rate 0:30:00
ChangeTempBasal RATE=3.5,
DURATION=1800000, ACTION_REQUESTOR=rf_diagnostic 1.71E+10 54770231 292 Paradigm
722

Here's the dump of the event's page pulled during the crash:
<5a0f7050 141d1015 13000800 00000000 00000000 00000000 00001e14 14211e00 00000000 00000000 00005f69 00000000 00000000 00000000 00000000 00000000 00151300 08000000 00000000 00000000 00000000 1e14142d 1e000000 00000000 00000000 5f690000 00000000 00000000 00000000 00000000 00000044 338c4055 145d1000 16014055 145d1033 3e445a14 5d100016 01445a14 5d10335a 4464145d 10001601 4464145d 10335e40 69145d10 00160140 69145d10 010a0a00 4a6b341d 10010f0f 00797934 1d10010a 0a00484b 351d1033 83445a15 5d100016 01445a15 5d10333c 4369155d 10001601 4369155d 10011919 006f7a35 1d10333c 4b41165d 10001601 4b41165d 10333c4e 55165d10 0016014e 55165d10 333c486e 165d1000 1601486e 165d1033 1b4c7316 5d100016 014c7316 5d10333c 5f4b175d 10001601 5f4b175d 10010808 00554d37 1d100108 08006a5d 371d1033 3c656417 5d100016 01656417 5d100105 0500766a 371d1033 3c487817 5d100016 01487817 5d100700 000a6a5d 906d5d90 050c00e8 00000000 0a6a0562 34050830 00000508 30000000 00000005 08641300 0000130c 00e80000 0033394a 50005e10 0016014a 50005e10 33394864 005e1000 16014864 005e1033 00496900 5e100016 01496900 5e103300 4878005e 10001601 4878005e 10330041 55015e10 00160141 55015e10 3348495f 015e1000 1601495f 015e1033 39456401 5e100016 01456401 5e103348 4a69015e 10001601 4a69015e 1033104c 73015e10 0016014c 73015e10 33394578 015e1000 16014578 015e1033 39455002 5e100016 01455002 5e103314 465a025e 10001601 465a025e 1033004a 5f025e10 0016014a 5f025e10 3300456e 025e1000 1601456e 025e1033 00424103 5e100016 01424103 5e103300 4550035e 10001601 4550035e 10330049 5f035e10 00160149 5f035e10 3300456e 035e1000 1601456e 035e1033 39467803 5e100016 01467803 5e10338c 4d46045e 10001601 4d46045e 10338c46 64045e10 00160146 64045e10 33444a41 055e1000 16014a41 055e1001 04040075 61281e10 33447968 085e1000 16017968 085e1033 4a797208 5e100016 01797208 5e103344 4478085e 10001601 4478085e 10334442 50095e10 00160142 50095e10 33147954 095e1000 16017954 095e1033 44415a09 5e100016 01415a09 5e10338c 7968095e 10001601 7968095e 10011414 006e6c29 1e103344 7972095e 10001601 7972095e 10335841 460a5e10 00160141 460a5e10 010a0a00 47492a1e 10336841 500a5e10 00160141 500a5e10 010a0a00 6b512a1e 10334441 5a0a5e10 00160141 5a0a5e10 33004150 0b5e1000 16014150 0b5e1033 00455f0b 5e100016 01455f0b 5e103346 416e0b5e 10001601 416e0b5e 10334641 460c5e10 00000000 00005a49>