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.

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 to your own devices to ensure the state of whatever thing you are buying as it likely…

Powering a mainframe

The last few days have been eventful. I was contacted by the datacenter that the mainframe's cage is now ready for moving in, and the power has been made available. Very exciting! I grabbed my home-made power cables (more on that later) and my best screwdrivers and set off to the datacenter.


The datacenter staff, not needing a forklift in their day-to-day, had managed to solicit the services of a forklift, the associated operator, and some very handy folks to help navigate the mainframe from the storage space to its final location.



After some intense period of fighting the inclination of the road between the storage facility and the cage (and a door that was a bit too small) it was finally in place. Incidentally we were forced to trust the wheels on this pretty rough floor. I did not expect it to roll that well on raw concrete, I was pleasantly surprised. This thing is a tank!

Now, everybody wanted to see if it was working. My machine did not come with a power cable so I had to so…

Open Datacenter Hardware - Leopard Server

Introduction The Leopard is an OpenRack v1 compliant 12V server commissioned by Facebook to offer compute power. It consists of 2x Intel Xeon E5-2678 v3 and is available with either DDR3 or DDR4 memory. The model is manufactured by two vendors primarily: Quanta and Wiwynn.

Leopard features a 24x PCIe slot which can fit either a PCIe card with low profile, or a riser card with 1x 16x and 1x 8x slots. The server also supports a 3.5" SATA drive as well as either an mSATA or an M.2 drive mounted on the motherboard.

Connectivity wise Leopard has a mezzanine card slot allowing for example 10Gb/s or 25Gb/s Ethernet.

Figure 1 and figure 2 shows the server layout. The server is made to fit inside an OpenRack v1 enclosure, at which point it looks something like figure 3. Due to power constraints an OpenRack v1 can fit 30 of these servers before power starts to become an issue. The Leopard servers that the organization Serverfarm Upstate provides are all fitted with 256GiB DDR3 RAM and 2x …