Analysizing data from Aston Martin 433MHz Smartire TPMS

MatthewRuddy commented 1 month ago

I have been trying to reverse decode the TPMS sensors for a 2008 Aston Martin, which uses a Smartire system with 433MHz TPMS sensors. I have no doubt they're similar to something already decoded with rtl_433, but can't quite figure out which sensors they are most like. I'm also pretty new to this!

I've been able to capture some data when running rtl_433 -S unknown, which I've attached. The sensors I'm using isn't inside a tyre, so it will be reading 0/1kpa, FYI. Temperature should work. I have an Autel TS408 TPMS programming device, which can activate the sensor remotely, which I'm doing to capture the data here with a Nooelec NESDR Smart V5 and an antenna.

Can anyone help point me in the right direction? I'm sure this sensor is similar to something already figured out here.

Thanks.

g012_433.92M_250k.cu8.zip g013_433.92M_250k.cu8.zip

zuckschwerdt commented 1 month ago

Try the sample file on https://triq.org/pdv/ -- it's quiet slow (for a TPMS) at 167 µs a half-bit, 6 kBps. And it uses OOK -- we normally see FSK at 50 µs. Use a decoding of MC with 167 / 167. Note that there is a 3 half-bit desync at the start.

Try a flex decoder like this and record some changes in temperature or pressure to spot those data fields. rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=167,l=167,r=600' The data from e.g. your first sample is {56}518c001e187f4b.

MatthewRuddy commented 1 month ago

Thanks for your reply @zuckschwerdt. I'm afraid I'm out of my depth here so I will have to figure out what most of that means 😅 I would make sense for the system to be slow - it was developed in the early 2000's and is known to be pretty mediocre.

I ran rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=167,l=167,r=600' and recorded two scenarios. One with the sensor just sitting on a table, and another with me spinning it around in a circular motion (to simulate a wheel). When spinning it, upon reading with the Autel TPMS programming device it showed 40kpa pressure. It seems moving the sensor around triggers it into providing a KPa value other than 0.

The Autel is showing NA when trying to read the temperature, so I can't confirm that value. It's likely ambient temp, which today was somewhere between 20-25c. I do believe these sensors do transmit temperature, or at least the Smartire system has a built in temperature warning when a single tyres temperature reaches 170F/75c (or around that number).

On table (no movement): on-table.txt

Spinning in circular motion (40kpa): spinning-around-40kpa.txt

MatthewRuddy commented 1 month ago

Another test later this evening. A few 0KPa reads, then a 70KPa read. All triggered via the Autel TS408 TPMS reader, and the later 70KPa reading by me again moving the sensor around quickly.

Before this latest test, I reprogrammed the sensor, but it appears to have the same ID as reported by the Autel reader. It reports the ID as 17489.

I can see a bit of a pattern - the code/data repeats with 518c001e187f4b every 1, 3, 5, 7, 9 times, etc. This never changes. That's as far as I've been able to figure out with my limited knowledge.

another-test-70kpa.txt

ProfBoc75 commented 1 month ago

@MatthewRuddy

Decimal ID = 17489 => 0x4451 = Hexadecimal ID, if you try the bellow command I found 0x4451 in the middle of the data from your cu8 files:

 rtl_433 -R 0 -X 'n=Aston-Martin-Smartire,m=OOK_PCM,s=167,l=167,r=600,preamble=32,decode_dm,get=id:@20:{16}'

from g012_433.92M_250k.cu8: 5 x times these values

{51}52800445103ba --> Fixed value, even with the other flex decoder and your text files, always same value
{51}53f404451011a

from g013_433.92M_250k.cu8: 5 x times these values

{51}52800445103ba --> Fixed value, even with the other flex decoder and your text files, always same value
{51}54040445100ea --> Few values changed, same from your text files, second message values changed a little.

For each transmit, you have 10 messages. ( Message A then B x 5 times ) Now, I'm not sure about the preamble, I can't find any CRC, so probably a checksum from these data to guess.

Try other TPMS sensors to see if you can identify the hexa values into the codes with my command.

Edit: I found from videos that the id is 6 nibbles coded - 3 bytes / more than 16 bit (Vantage Smartire / Aston Martin DB9 protocol, from 1/2005 till 12/2011).

This will get the ID from 22 bits: (2 first bits are excluded because the ID is not same in second message B)

rtl_433 -R 0 -X 'n=Aston-Martin-Smartire,m=OOK_PCM,s=167,l=167,r=600,preamble=32,decode_dm,get=id:@14:{22}'

We can get the ID from 24 bits with get=id:@12:{24} but the second message B the ID is not the same.

bitbench

MatthewRuddy commented 1 month ago

Thanks @ProfBoc75 that's really helpful and made some good progress. ID is correct - I've been able to reprogram a spare sensor with custom IDs and each time it's been correct. I've also figured out the temperature reading has an offset of 40, so figured out this much:

5 31 58 96 7f 02 e2 [ID 1611391, 0x31 = 49 - 40 = 9c, put in fridge for 5 mins, 0kpa]
5 14 58 96 7f 03 e2 [ID 1611391, 0x14 = 20 - 40 = -20c, put in freezer, 0kpa]
5 27 58 96 7f 01 7a [ID 1611391, 0x27 = 39 - 40 = -1c, out of freezer warmed in hand 2 mins later, 0kpa]
5 2f 58 96 7f 00 02 [ID 1611391, 0x2f = 47 - 40 = 7c, still warming up, 0kpa]
5 3a 58 96 7f 00 3a [ID 1611391, 0x3a = 58 - 40 = 18c, warmed up in hand again, 0kpa]

I did notice that in the above strings, the ID parts are missing a leading 1. ID 1611391 = 18967F but I'm only seeing 58967F here. The max ID I can program is 9999999 (7 digits) FYI. 8 digit IDs are not supported (can't be programmed by the Autel reader).

I'm still unsure on pressure. Can't find a correlation. The chip in this TPMS is a Sensornor SP11A, but I can't find any datasheets/documentation about it. I have found the datasheet on a newer variant of the IC used in another TPMS sensor, which might give some clues (it gave me the -40c offset for temp). It uses the SP13 version of the chip, which is 6/7 years newer - https://www.alldatasheet.com/datasheet-pdf/view/208717/MICROCHIP/AN238.html.

The sensor is also transmitting some sort of battery/voltage status.

ProfBoc75 commented 1 month ago

@MatthewRuddy

I guessed the data layout, at least the first part, missing the checksum not yet decoded.

bitbench:

? 4h TEMP/PRESSURE 8d MESSAGE_TYPE 2b ID 22d FLAG ? 4b CHECKSUM ? 8h TRAILING ? 4h

Message_type is 2 bit flags, 00 or 01

The ID is 22 bit coded and it match with your new ID, just to confirm, did you try to set ID 9 999 999 ? And not only able to program but also able to read the ID 9999999 from your Autel device. As for me the max is 4194303 / 0x3FFFFF (22 bits)

About the data layout, could be: Message A (type b00) = Pressure offset 40, Message B (type b01) = Temp, offset 40.

More details here: Bitbench

MatthewRuddy commented 1 month ago

Thanks @ProfBoc75 - you're correct. I was actually writing a response as you posted! :)

I put the sensor inside a garden pressure sprayer and was able to simulate pressures. Using the data below, I've figured the formula is X - 40 = Y * 2.5 = Z, Z being the KPa value. Similar to the datasheet above, but with an offset like the temperature of -40. Here is a couple of values I recorded:

5 37 18967f 03 d2 (0x37 = 55) ((55 - 40) * 2.5 = 38kpa)
5 42 58967f 01 c2 (0x42 = 66) ((66 - 40) = 26c)

548 18967f 02 22 (0x48 = 72) ((72 - 40) * 2.5 = 80kpa)
543 58967f 00 a2 ((66 - 40) = 27c)

5 56 18967f 00 c2 (0x56 = 86) ((86 - 40) * 2.5 = 115kpa)
5 43 58967f 00 a2 ((67 - 40) = 27c)

5 64 18967f 03 3a (0x64 = 100) ((100 - 40) * 2.5 = 150kpa))
5 41 58967f 02 62 ((65 - 40) = 25c)

I was able to confirm these with the Autel reader.

Nearly there! Very promising, although unusual it comes as two messages.

I will try 9999999 as an ID - you're probably correct here.

Update: Yes the max sensor ID value is 4194303 (0x3FFFFF) 👍

ProfBoc75 commented 1 month ago

@MatthewRuddy :

Can you please share other samples, as I need more to guess the checksum, I'm close to the good one, 2 possibilities for the moment guessed with revdgst, but I'm not sure about the exact position of the checksum, looks like it could be shifted a little, the flags before it could be less with 4 or 6 bits then the checksum (see the bitbench below)

Done with g 0c k 0c final XOR ae using xor xor (100 %)
Done with g 8a k 8a final XOR 28 using xor xor (100 %)
Time elapsed in s: 0.03 for: Rev-Galois BYTE_REFLECT

Another point, we need more use cases, like: fast pressure increase, fast pressure decrease, low bat, and rolling wheel to identify some flags somewhere into the data layout. Notice that a normal pressure around 250 kPa could also trigger flag.

bitbench updated with your last findings

MatthewRuddy commented 1 month ago

@ProfBoc75 I will try get some more in-car readings for you over the weekend. Might be difficult as only one sensor currently works (they're all 14 years old!). The sensor I've been testing with isn't installed.

I'm still using the garden pressure spray bottle to simulate the increase and decrease in pressures. I'm not sure if this is useful. Here are the results. The highest I can get it to go is 235/240kpa.

rapid-decrease.txt rapid-increase.txt

I had to use the Autel reader to trigger these readings as the sensor itself doesn't seem to transmit data very often (possibly because it's not rotating).

I ran the commands with -W flag and can upload those files if also useful? They're quite large, 33mb and 66mb respectively.

ProfBoc75 commented 1 month ago

@MatthewRuddy: if you recorded files, you can zip them into single file and upload here as you did already. This will let me test them / replay the files.

zuckschwerdt commented 1 month ago

quite large, 33mb and 66mb respectively.

Perhaps best to upload such big files somewhere else, e.g. some free file hoster.

MatthewRuddy commented 1 month ago

Here are files for above tests. Still waiting to do in-car tests. :smile: https://www.dropbox.com/scl/fi/sscc3tu37djqvvtocb72f/rtl_433_rapid_increase_decrease.zip?rlkey=0aloumt77t3z6j9aq7pdlvrc2&st=vo23uat1&dl=0

ProfBoc75 commented 1 month ago

@MatthewRuddy

Some findings and good news, I guessed the CRC and found Fast Pressure Increase Flag position, but still needs some clarification.

The message is based on 6 bytes, but missing the last bit, expected 48 bits, and we have 47 bits.
Looking at the last byte and the 2 or 3 last bits (LSB), they are always xxxxx01 (7bits) or xxxxx010 (8bits), but I found a CRC-7 here, poly 0x45, init 0x6f , final xor 0x00.
Looking before last byte, the first MSB bit is Fast Pressure Increase flag, the last 2 LSB bits are may be linked to CRC or Parity or XOR ???, here the issue, because of the 2 or 3 last bits of the last byte are always the same, these 2 last bits could be part of CRC (MSB/LSB ?), but in that case I'm not able to find the algorithm. And these 2 bits are not linked to a flag behavior at Temp nor Pressure level, but previous bits for sure, like a checksum.

About behavior, in case of fast pressure increasing a single message is sent with the flag to 1 and pressure value, following 10 messages with the new pressure / temp, still flag to 1, and sent every 1.5 or 2 seconds. When the pressure is stable, the flag disappeared, and message sent less often.

I did not see flag when pressure decreased.

Bitbench updated

ProfBoc75 commented 1 month ago

@MatthewRuddy , I created the pr #3072 with a draft version of the decoder, which is working from my side with your sample files.

Please, test and let me know here or into the pr if you have any findings/improvement or correction.

MatthewRuddy commented 3 weeks ago

Thank you @ProfBoc75, I will test this as soon as I can. Will share any findings.

I finally managed to get in-car driving data. This is from a 10 minute drive, with some traffic: driving.txt. I forgot to run -W, my apologies.

I think it's actually plausible that two of the sensors are working - I'm unsure (IDs 113640 and 1119036).

ProfBoc75 commented 3 weeks ago

@MatthewRuddy:

We have 2 new types into your last driving.txt file, across 3 IDs.

Message type b10 ( = 2), with different values (0x82 = 130, 0x85 = 133, 0x80 = 128), need more sample, (speed/wheel position ??? ) as we have only one value for each sensor,
Message type b11 ( = 3), always with the same value 0xa8 = 168, whatever the sensor ID. optimal pressure / battery level / ??? This value was repeated several times, always before and after message type 2, see table here:

Sorted by Sensor ID then Date Time. Date Time	Codes	Value (dec)	Message	ID	Pressure kPa	Temp °C
24/10/2024 08:07:33	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:33	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:07:34	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:34	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:07:34	{51}5a8c194d502da	168	3	103637
24/10/2024 08:07:34	{51}5808194d50032	128	2	103637
24/10/2024 08:07:34	{51}5a8c194d502da	168	3	103637
24/10/2024 08:07:34	{51}5a8c194d502da	168	3	103637
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:07:52	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:07:52	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:08:10	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:10	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5434194d501b2	67	1	103637		27
24/10/2024 08:08:11	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5434194d501b2	67	1	103637		27
24/10/2024 08:08:11	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:11	{51}5434194d501b2	67	1	103637		27
24/10/2024 08:08:29	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:29	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:29	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:29	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:29	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:08:29	{51}5860194d501ea	134	0	103637	235
24/10/2024 08:08:29	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:08:29	{51}5424194d500d2	66	1	103637		26
24/10/2024 08:03:27	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:03:27	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:27	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:03:27	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:27	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:03:27	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:27	{51}5a8c1bbe8018a	168	3	113640
24/10/2024 08:03:27	{51}58581bbe801aa	133	2	113640
24/10/2024 08:03:27	{51}5a8c1bbe8018a	168	3	113640
24/10/2024 08:03:45	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:45	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:45	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:45	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:45	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:46	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:46	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:46	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:46	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:03:46	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:04	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:04	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:22	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:04:23	{51}58c01bbe80102	140	0	113640	250
24/10/2024 08:04:23	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:06:14	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:06:14	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:06:15	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:06:15	{51}58e01bbe803c2	142	0	113640	255
24/10/2024 08:06:15	{51}53f41bbe800b2	63	1	113640		23
24/10/2024 08:03:20	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:03:20	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:20	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:03:20	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:20	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:03:20	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:20	{51}5a8d1133c0232	168	3	1119036
24/10/2024 08:03:20	{51}58291133c021a	130	2	1119036
24/10/2024 08:03:20	{51}5a8d1133c0232	168	3	1119036
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:39	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:39	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}58b11133c02b2	139	0	1119036	247.5
24/10/2024 08:03:58	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:04:16	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:04:17	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:04:17	{51}54051133c02fa	64	1	1119036		24
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}54151133c039a	65	1	1119036		25
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}54151133c039a	65	1	1119036		25
24/10/2024 08:07:30	{51}58c11133c02ba	140	0	1119036	250
24/10/2024 08:07:30	{51}54151133c039a	65	1	1119036		25

Looks like the message type is repeated in same order, in sequence. 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 3, 2, 3, 0, 0, 0, 0, .... or 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0 ... strange ...

No sure if you were always driving during the capture, but the message 2 & 3 are very few compare to the 0 & 1 messages more frequent.

MatthewRuddy commented 3 weeks ago

That is odd, I'm not sure what these values could be. The box/device that receives the signals and triggers dashboard errors provides limited information. Maybe it's a clue? The only errors it seems to provide are:

Tire pressure low
Tire pressure VERY low
Tire over temperature
Tire pressure ‘changing’ at a pace faster than it should
Sensor Failure
Control Unit failure.

When any of these are triggered, the dash says "Tyre System Fault" and you have to refer to indicator LEDs on the box/device to determine which tyre is the culprit. TLDR, it's really old school.

I stopped during the drive maybe 3 times for more than 20 seconds (traffic and lights). Otherwise, didn't reach over 60kph. Will try get some more data when possible.

I'm also going to remove the box/receiver device from the car (when possible) and see if I can replay some of these commands and trigger the error states to simulate these scenarios. This may be helpful.

merbanan / rtl_433

Analysizing data from Aston Martin 433MHz Smartire TPMS #3067