Agilent N8973A Noise figure Analyzer - garbage out even at bit_depth = 7

[KermitW9XA]

Hello ALL -

I am looking for suggestions and help. At this point my main goal is to be able to "print" from the Agilent NFA 8973A and create PDF files which I see on a Windows11 computer.

I have a V4 RetroPrinter running on a suitable Raspberry Pi was required in the RetroPrinter instructions.
( Linux retro-printer 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1~bookworm (2026-03-11) aarch64 )
that I using to connect to an Agilent 8973A Noise Figure Analyzer. I have the RetroPrinter working with CUPS to feed a network printer and also I have the printout\\Retro-Printer available as a Z: drive on a Windows 11 machine. The configuration of CUPS was quick and seamless - the netwrk printer works perfectly with control and test pages from the Retro-printer:631 control page. The pcl and pdf files do appear in the shared "drive" without a problem. The only issue is that the PCL file (which I read with a separate program), the PDF and the printed copy are all garbled. I have changed the bit_depth to a setting of 7, as discussed elsewhere - but that has not helped. Also, the output is similar on the pcl file to the pdf andprinted copy - except the pcl shows line feeds, whereas the PDF and printed copy have strikeovers - it looks like the printer output file without the Ghost processing it into png. ALSO - I never see a PNG file created or left.

The source device is an Agilent 8973A Noise Figure Analyzer running firmware A.01.12 dated 26Nov2004. The 8973A has a dedicated parallel printer port on a DB25, which is connected to the RetroPrinter server by means of a parallel-to-Centronix cable I obtained for the folks at Retro-Printer.

The Agilent 8973A manual has sparse comments on the printer interface, of course it is primarily meant to work with PCL3 and PCL5 printers. The manual does state;

IEEE 1284 compliant printer cable.
• Supported printer equipped with a parallel interface. A supported printer
is one that accepts Printer Control Language Level 3 or 5.
— PCL3 printers include most HP DeskJet printers.
— PCL5 printers include most HP LaserJet printers and the HP 1600C
DeskJet printer.

The 8973A NFA has three menu setting for printer set-up; None, Auto, or Custom. Auto doesnt respond - it indicates that no printer is available so I have been using "Custom". There is a "Custom SetUp" with two parameter; PCL3 or PCL5 and color or black only. Any combination or those choices seems to make no difference to the scrambled character output. There are two options for printing; one which is a report in plain text and the screenshot of the measurements as they appear on the instrument screen. The only difference is the size of the file created, they are both scrambled,

I have changed bit_depth and in an effort to conserve paper and Ink I have been working with the printer_output to "No", and have been looking at the output PDF and PCL files, which appear to be the same constant

The setting that I currently have on the RetroPrint setup on /root/config are as follows;

bit_depth 7
emulation HP
handshaking 4 ( was 0 but I have also tried 1 through 4 )
interface Centronix
machine Raspberry
offline_switch No
output _path /home/pi/data
output_PDF Yes
output_PNG Yes
output_printer No ( changed from Yes to avoid fifty sheets spent with a few lines strike-over text on each page)
retain_data Yes
usb_passthrough No
all other settings not mentioned remain in the default configuration, the script files have not been edited or changed.

I access the RetroPrinter Pi using the BitVise xterm for editing.

Does anyone have any suggestions as to what to try next ? I must note that I have never seen a PNG file - and the scrambled characters that I see in the PCL, PDF and printouts on the network printer all appear as if the GhostPCL is not processing the PCL files in the PrintPCL.sh script.

Thank You,

73, Kermit Carlson W9XA
W9XA@yahoo.com

[RWAP]

As you have them emulation set to HP, then the process for creating the PDF is completely different.

You will never see a PNG created, as once the data is captured (and stored in /tmp/pdf), then the printpcl.sh script launches GhostPCL to convert the data directly to a PDF.

If the PCL output is corrupt this can be for various reasons:

a) The Handshaking setting (4 is extremely unusual). We are currently looking at v3.37 of the Retro-Printer capture software to add two more settings for this. Normally 0 or 2 work best. Unfortunately, some machines are stubborn and do not always abide by the busy and acknowledge signals before sending the next byte!
b) Odd print codes are being sent by the machine which are outside the specification for PCL data and therefore confusing GhostPCL
c) Some specific print code sequences sent by the machine are themselves corrupt - we have had to address these using exchange_strings for one customer recently.
d) You may also need to look at the printer_delay setting (if you get repeated characters in the PCL data).

Upload a sample pcl file here and the expected printout so we can look at it.

[KermitW9XA]

Hello -
Thank you for the suggestions, I tried to print again from the 8973A NFA with the handshaking setting at 2, similar results. Attached is the pdf file of the most recent attempt and the PCL file - since the message board would not accept the .PCL file extension I changed it to .txt - hopefully it is not too corrupted to change back to a.pcl file .... but I did convert this PCL file to a PDF using the api online app - it is attached as 0000.pdf

I have received an email from Rich that has instructions to overwrite /home/pi/temp/sdl/escparser files to adjust timing and add more settngs, which I will try shortly. That is very much appreciated Rich !

Thank You,

Kermit

[KermitW9XA]

Hello -
Attached is a low-resolution screenshot of printed report that was to be printed and mentioned as 0000.pdf and 0000.pcl in the previous post
Thank You
Kermit

[RWAP]

Thanks for the files - that is certainly odd, the PCL data starts with ESC E
However, it receives $19 $45 instead of $1B $45
- it seems as though all of the ESC characters are being sent as $19 (decimal 25) when they should be $19 (decimal 27).

I wonder if bit 1 is not coming on for some reason - as the next code sequence is probably
ESC &10A
$1B $26 $6C $30 $41
but it is
$19 $24 $6C $30 $41

I normally check the capture with a string like:

Hello World 2026-06-19 15:23:00

So that does check all of the bits including bit 2 so that suggests a cable issue (or possibly the HAT is not screwed down onto the Raspberry Pi GPIO pins properly).