PPG Events

[r3dunlop]

The data format for PPG events are as follows:

The header is parse the same way as a GRIFFIN header (label (0x8) ). If the Data Type received from the header is 4 and the channel address is 0xFFFF, then this is a PPG event.

• The next word may, or may not have a network packet (0xd), parsed like griffin.
• The next word is the new ppg pattern, starts with 0x0, the next 28 bits are the pattern
• The next word is the old ppg pattern, starts with 0x9, the next 28 bits are the pattern
• The next word may or may not be the network packet (see above)
• The next word is the PPG low time stamp, starts with 0xa next 28 bits are the low time
• The next word is the PPG high time stamp, starts with 0xb, next 28 bits are the high time
• The next word is the trailer, starts with 0xe, last 16 bits are a repeat of last 16 bits of new ppg.

I'm pretty sure the PPG patterns are actually only 16 bits, so it's 12 truncated PPG bits concatenated with 16 ppg bits in every one of the "28 bit" pattern cases.

[VinzenzBildstein]

I think that is the old interpretation of the PPG format, now the "new" PPG pattern is the requested PPG pattern and the "old" PPG pattern is the actual PPG pattern (as read back from the PPG).

[r3dunlop]

Ah, we should put some comments or change the naming scheme in the GRSISort data parser then.

On Nov 13, 2015, at 1:35 PM, Vinzenz Bildstein notifications@github.com wrote:

I think that is the old interpretation of the PPG format, now the "new" PPG pattern is the requested PPG pattern and the "old" PPG pattern is the actual PPG pattern (as read back from the PPG).

— Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/data-spy/issues/5#issuecomment-156512224.

[SmithJK]

This is inconsistent with some of the PPG patterns from the last run:

0x820ffff0 0xdd771329 0x0008c008 0x9008c008 0xa0000000 0xb0000000 0xe0000000
0x820ffff0 0xd0000000 0x0002c002 0x9002c002 0xa8f0d1c0 0xb0000000 0xe008c008
0x820ffff0 0xd0000000 0x0001c001 0x9001c001 0xaee6b2c2 0xb0000000 0xe002c002
0x820ffff0 0xd0000000 0x0004c004 0x9004c004 0xa03e0562 0xb0000001 0xe001c001

Based on these, I think that the last word is now 28 bits of the Old PPG. Obviously, this doesn't leave us with a corruption check, though I suppose the repetition within the pattern itself is a decent check.

[VinzenzBildstein]

That is exactly what I said (though I left out that the old PPG status is now in the trailer). We used to read the new PPG, then the old PPG, and find the new PPG repeated in the trailer. This was (I think) the case for the Cd/In experiments in August. Since then the format has changed (though not the TPPG class). Now we get the requested new PPG pattern, then the read back new PPG pattern, and the old PPG in the trailer. The only thing we changed in the GRSISort code was to omit the check of the trailer vs the new PPG, meaning we're storing the requested PPG as new PPG, and the read back PPG as old PPG.