Skip to main content

LeCroy 9350AM revisited

Yesterday I got a sort of crazy idea: "What if I could make my oscilloscope hardcopy to email instead of the broken built-in printer?". As it turns out, the LeCroy 93xx series is capable of both accepting remote control commands and dumping hardcopies to the same RS-232-C bus - write 'SCREEN_DUMP' and it will dump it in the same session, pretty sweet.

The 93xx series features quite a lot of output formats ranging from BMP and all the way to some odd format called HP 7550 which I assume is before my time - BMP and TIFF sadly taking 40 seconds at 19200 baud to fully process. HP 7550 took around 9 seconds, but after some googling I gave up on that format - it seemed to be very troublesome to get something working with that format. Finally I settled for the compressed TIFF format (12 seconds @ 19200 baud) - the problem was that the file received from the oscilloscope was not something libtiff gladly wanted to process.


When I gave the file to imagemagick's identify program, it didn't want to play along.
# identify -verbose filecomp.tiff
Image: filecomp.tiff
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 816x696+0+0
  Resolution: 121.791x148.085
  Print size: 6.7x4.7
  Units: PixelsPerInch
  Type: Bilevel
  Base type: Bilevel
  Endianess: MSB
  Colorspace: RGB
  Rendering intent: Undefined
  Interlace: None
  Background color: white
  Border color: rgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Compose: Over
  Page geometry: 816x696+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: RLE
  Orientation: TopLeft
  Properties:
    date:create: 2011-03-09T17:48:01+01:00
    date:modify: 2011-03-09T17:48:01+01:00
    signature: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    tiff:photometric: min-is-white
    tiff:rows-per-strip: 696
  Artifacts:
    verbose: true
  Tainted: False
  Filesize: 28.7KB
  Number pixels: 568KB
  Pixels per second: 0b
  User time: 0.010u
  Elapsed time: 0:01.000
  Version: ImageMagick 6.6.0-4 2010-11-16 Q16 http://www.imagemagick.org
identify: incorrect count for field "ColorMap" (768, expecting 6); tag trimmed. `filecomp.tiff' @ warning/tiff.c/TIFFWarnings/703.
identify: filecomp.tiff: Read error on strip 0; got 26911 bytes, expected 70992. `TIFFFillStrip' @ warning/tiff.c/TIFFErrors/493.


Fair enough. I tried to open it in Photoshop which to my great surprise actually worked - which meant that all the data was available but the format was corrupted.

Libtiff was helpful enough to provide me with a number: 70992 and 26911 - 70992 is located as a long at 0x7E in the TIFF header, but what about 26911? Replacing 70922 with 26911 fixed this one TIFF, but I needed to know how to calculate this number. This is where the utility called exiftool comes along.

# exiftool -g1 -D filecomp.tiff
---- ExifTool ----
    - ExifTool Version Number         : 8.15
---- System ----
    - File Name                       : filecomp.tiff
    - Directory                       : .
    - File Size                       : 28 kB
    - File Modification Date/Time     : 2011:03:09 17:48:01+01:00
    - File Permissions                : rw-r--r--
---- File ----
    - File Type                       : TIFF
    - MIME Type                       : image/tiff
    - Exif Byte Order                 : Big-endian (Motorola, MM)
---- IFD0 ----
  255 Old Subfile Type                : Full-resolution image
  256 Image Width                     : 816
  257 Image Height                    : 696
  258 Bits Per Sample                 : 1
  259 Compression                     : PackBits
  262 Photometric Interpretation      : WhiteIsZero
  273 Strip Offsets                   : 1746
  277 Samples Per Pixel               : 1
  278 Rows Per Strip                  : 696
  279 Strip Byte Counts               : 70992
  282 X Resolution                    : 121.7910448
  283 Y Resolution                    : 148.0851064
  284 Planar Configuration            : Chunky
  296 Resolution Unit                 : inches
  320 Color Map                       : (Binary data 1536 bytes, use -b option to extract)
---- Composite ----
    - Image Size                      : 816x696


Some quick math: file_size - 26911 = 1746 (Strip Offsets). In reality I did check how libtiff calculates the error message's "expect" value and then verified it with exiftool, but you get the idea.

Result: 9350_fix_tiff.py
import struct

def fix_tiff (f):
  f.seek (0, 2)
  file_size = f.tell()

  # Get 'Strip Offsets'
  f.seek (0x5A)
  real_size = file_size - struct.unpack ('>I', f.read (4))[0]
  print 'Patching to', real_size
  
  # Write 'Strip Byte Counts'
  f.seek (0x7E)
  f.write (struct.pack ('>I', real_size))


This script has evolved and now contains an SMTP function which sends the hardcopy as a color and B/W attachment (PNG format) to my email when I press "Screen dump". Pretty neat if I may say so myself.

Comments

Popular posts from this blog

Buying an IBM Mainframe

I bought an IBM mainframe for personal use. I am doing this for learning and figuring out how it works. If you are curious about what goes into this process, I hope this post will interest you. I am not the first one by far to do something like this. There are some people on the internet that I know have their own personal mainframes, and I have drawn inspiration from each and every one of them. You should follow them if you are interested in these things: @connorkrukosky @sebastian_wind @faultywarrior @kevinbowling1 This post is about buying an IBM z114 mainframe (picture 1) but should translate well to any of the IBM mainframes from z9 to z14. Picture 1: An IBM z114 mainframe in all its glory Source: IBM What to expect of the process Buying a mainframe takes time. I never spent so much time on a purchase before. In fact - I purchased my first apartment with probably less planning and research. Compared to buying an apartment you have no guard rails. You are left

zBC12, the new family member

Yesterday after more than a year's delay my zBC12 mainframe finally booted up. This is a machine that was donated to me in hopes to advance the hobbyist community, which I am eternally grateful for. Image 1: Athena, the zBC12 that just now got online Then what is the main selling point of the zBC12 versus the z114? You might recall my article  System z on contemporary zLinux  where I explained that running modern Linux on a z114 is hard. This is the main selling point for me to upgrade - being able to run things like more modern Linuxes than z114. While the latest OSes in zLinux, z/VM, and z/OS require z13 or newer - a zBC12 still allows me to run a few releases newer software. Image 2: The operator himself in the picture with Athena Perhaps one of the bigger deals that is very welcome is the support for OSA-Express5S. This means that while previously you needed both PCIe and I/O bays in order to have both effective higher speed connectivity like 8G FC or 10 GB Ethernet as well as

Brocade Fabric OS downloads

Fabric OS is what runs on the SAN switches I will be using for the mainframe. It has a bit of annoying upgrade path as the guldmyr blog can attest to. TL;DR is that you need to do minor upgrades (6.3 -> 6.4 -> 7.0 -> ... > 7.4) which requires you to get all  Fabric OS images for those versions. Not always easy. So, let's make it a bit easier. Hopefully this will not end up with the links being taken down, but at least it helped somebody I hope. These downloads worked for me and are hash-verified when I could find a hash to verify against. Use at your own risk etc. The URLs are: ftp://ftp.hp.com/pub/softlib/software13/COL59674/co-168954-1/v7.3.2a.zip ftp://ftp.hp.com/pub/softlib/software13/COL59674/co-157071-1/v7.2.1g.zip ftp://ftp.hp.com/pub/softlib/software13/COL59674/co-150357-1/v7.1.2b.zip ftp://ftp.hp.com/pub/softlib/software12/COL38684/co-133135-1/v7.0.2e.zip ftp://ftp.hp.com/pub/softlib/software13/COL22074/co-155018-1/v6.4.3h.zip ftp://ftp.hp.c