diff --git a/libsharperang/usb.cs b/libsharperang/usb.cs
index bba2b61..208f734 100644
--- a/libsharperang/usb.cs
+++ b/libsharperang/usb.cs
@@ -6,43 +6,6 @@ using LibUsbDotNet.Main;
 
 
 /*
- * the official software seems to transmit a CRC "token" on first detecting the printer (Paperang P1; MiaoMiaoJi):
- * Frame.Begin, PrinterCmd.TransmitCrc, 0x4d0dc477, 0x699295ed, Frame.End
- * This differs when connected to a Paperang P2:
- * Frame.Begin, PrinterCmd.TransmitCrc, 0x18d2a3df, 0x4ec92265, Frame.End
- * 
- * It's not immediately clear to me whether the segment normally containing the CRC is itself a CRC of the token
- *  or if the token is simply 8 bytes rather than 4 and the CRC segment of the frame is omitted for this operation
- * 
- * From what I can tell, calculation of a CRC32 checksum can involve a polynomial and a 'check' value.
- *  It may thus be possible that the Data value is the 'check' value, and the CRC value is the polynomial..
- * In ihciah/miaomiaoji:message_process:crc32(data), the CRC32 value is generated by the zlib.crc32(d,v) function
- *  however I've been unable to reproduce a checksum of 0x906f4576 from a starting value of 0x00 and a polynomial
- *  of any variation of 0x4d0dc477, 0x699295ed
- * Disassembly of the official software indicates it -is- crc32 that's in use, however further investigation is needed
- * Finally, it's not clear whether this value transmitted is required to remain the same at all times
- *  or if the software may use whatever value it wants (whether this is simply a handshake, or whether the specific
- *  value "unlocks" communication with the printer
- * 
- * standard presence checks performed by the official software consist of simply sending two messages every two seconds:
- * Frame.Begin, PrinterCmd.SessionStart, 0x0000, 0x906f4576, Frame.End
- * Frame.Begin, PrinterCmd.SessionEnd, 0x00, 0x906f4576, Frame.End
- * 
- * printing out a blank page yields a 1018-byte payload formed of:
- * Frame.Begin, PrinterCmd.BeginPrint, 0x00*1008, 0x83c0e20f, Frame.End
- * followed by a 634-byte payload formed of:
- * Frame.Begin, PrinterCmd.ContinuePrint, 0x00*624, 0xbc1b6bf4, Frame.End
- * followed by a 12-byte payload formed of:
- * Frame.Begin, PrinterCmd.SessionEnd, 0x2c01, 0xa8347338, Frame.end
- * 
- * printing out a single dash ('-') yields a 1018-byte payload formed of:
- * Frame.Begin, PrinterCmd.BeginPrint, 0x00*858, 0x0fe0, 0x00*46, 0xfe0, 0x00*94, 0xc53ad770, Frame.End
- * followed by a 634-byte payload formed of:
- * Frame.Begin, PrinterCmd.ContinuePrint, 0x00*624, 0xbc1b6bf4, Frame.End
- * followed by a 12-byte payload formed of:
- * Frame.Begin, PrinterCmd.SessionEnd, 0x2c01, 0xa8347338, Frame.end
- * 
- * based on the above we can extrapolate that:
  * - 12 bytes is the minimum size of a payload, and 1018 bytes is the maximum
  * - all frames sent to the printer follow the structure of:
  * -- Frame.Begin (1 byte)
@@ -50,13 +13,6 @@ using LibUsbDotNet.Main;
  * -- Data (min. 2 bytes? max. 1008 bytes)
  * -- CRC32 sum of the Data block (4 bytes)
  * -- Frame.End (1 byte)
- * 
- * Also of interest is that, when a model P2 is connected, the printer will actually reply to messages
- * eg., for the standard presence check of Frame.Begin, 0x1a000200, 0x0000, CRC, Frame.End
- * the printer will reply with an almost identical message:
- * Frame.Begin, 0x1a000100, 0x00, CRC, Frame.End
- * The Data segment is a different size (one byte) and the printer appears to be doing its own CRC calculation
- * Finally, the command, 0x1a000100, appears to be an acknowledgement of sorts in response to PrinterCmd.SessionEnd (byte 3 changing from 0x02 to 0x01)
  */
 
 namespace libsharperang {
@@ -75,7 +31,6 @@ namespace libsharperang {
 		private byte[] ResolveOpcode(Opcode opcode) {
 			switch (opcode) {
 				case Opcode.SessionBegin:  return new byte[] { 0x06, 0x00, 0x02, 0x00 };
-				case Opcode.SessionEnd:    return new byte[] { 0x1a, 0x00, 0x02, 0x00 };
 				case Opcode.CrcTransmit:   return new byte[] { 0x18, 0x01, 0x04, 0x00 };
 				default: throw new NullReferenceException();
 			}