Archive for category PC Tweakage
Sena PS410 Serial Server: Capturing HP 54602 Screen Images
Posted by Ed in Electronics Workbench, PC Tweakage, Software on 2018-04-03
The objective is to capture screen shots from my HP 54602 oscilloscope, now connected to Serial Port 1 of the Sena PS410 serial server.
Although the scope command language offers a :PRINT? command, it produces output in HP PCL, from which there seems no practical way to get a raster image format like PNG. So this remains an output-only transfer triggered by poking the PRINT SCREEN softkey, after first setting the serial parameters:
HP 54602 scope serial parameters
In text:
- Connect to: HP Plotter
- Factors: ON
- Resolution: HIGH
- Baud rate: 19200 b/s
- Handshake: XON
I have no idea what’s inside the serial cable at this late date (see the HP 8591 post for more musings), but the (paper!) manual says:
For three-wire operation, an XON/XOFF software handshake must be used to handle handshaking between the devices.
For extended hardwire operation, handshaking may be handled either with XON/XOFF or by manipulating the CTS and RTS lines of the oscilloscope.
For both three-wire and extended hardwire operation, the DCD and DSR inputs to the oscilloscope must remain high for proper operation.
With extended hardwire operation, a high on the CTS input allows the oscilloscope to send data and a low on this line disables the oscilloscope data transmission.
Likewise, a high on the RTS line allows the controller to send data and a low on this line signals a request for the controller to disable data transmission.
Since three-wire operation has no control over the CTS input, internal pull-up resistors in the oscilloscope ensure that this line remains high for proper three-wire operation.
Apparently, the DCD, DSR, and CTS inputs have internal pullups.
Hardware handshakings uses these signals:
- Pin 4 RTS (Request To Send) is an output from the oscilloscope which can be used to control incoming data flow.
- Pin 5 CTS (Clear To Send) is an input to the oscilloscope which controls data flow from the oscilloscope.
- Pin 6 DSR (Data Set Ready) is an input to the oscilloscope which controls data flow from the oscilloscope within two bytes.
- Pin 8 DCD (Data Carrier Detect) is an input to the oscilloscope which controls data flow from the oscilloscope within two bytes.
- Pin 20 DTR (Data Terminal Ready) is an output from the oscilloscope which is enabled as long as the oscilloscope is turned on.
The scope wiggles them thusly:
The TD (Transmit Data) line from the oscilloscope must connect to the RD (Receive Data) line on the controller. Likewise, the RD line from the oscilloscope must connect to the TD line on the controller.
The RTS (Request To Send) line is an output from the oscilloscope which can be used to control incoming data flow. A high on the RTS line allows the controller to send data, and a low on this line signals a request for the controller to disable data transmission.
The CTS (Clear To Send), DSR (Data Set Ready), and DCD (Data Carrier Detect) lines are inputs to the oscilloscope which control data flow from the oscilloscope (Pin 2). Internal pull-up resistors in the oscilloscope assure the DCD and DSR lines remain high when they are not connected.
If DCD or DSR are connected to the controller, the controller must keep these lines and the CTS line high to enable the oscilloscope to send data to the controller. A low on any one of these lines will disable the oscilloscope data transmission.
Dropping the CTS line low during data transmission will stop oscilloscope data transmission immediately.
Dropping either the DSR or DCD line low during data transmission will stop oscilloscope data transmission, but as many as two additional bytes may be transmitted from the oscilloscope.
The “as many as two additional bytes may be transmitted” suggests the same problem as with the HP 8591 spectrum analyzer at 19200 b/s, wherein it seems to overrun the PS410 input despite the flickering CTS control line.
I set up hardware handshaking in the PS410 and discovered the CTS line flickers as it does with the 8591, but the transfer complete without overruns. Perhaps the 8591 sends more than however many characters the PS410 can handle after calling for a pause?
The Kermit setup points to Serial Port 1 on the PS410:
set host 192.168.1.40 7001 /raw-socket set modem none
And then the rest of the script Just Works:
Calibrator waveform
The Kermit script as a GitHub Gist:
Sena PS410 Serial Server: Capturing HP 8591 Screen Images
Posted by Ed in Amateur Radio, Electronics Workbench, PC Tweakage, Software on 2018-04-02
The objective is to capture screen shots from the HP 8591 spectrum analyzer, now connected to Serial Port 2 of the Sena PS410 serial server.
My analyzer is an old one with a 3322A serial number, so its Opt 023 came with a genuine DB-25 female connector, not the DE-9 male connector described in the HP doc for the later Op 043 hardware. With that in mind, the HP doc says the spectrum analyzer supports only hardware handshaking:
- Baud rate 300 to 57,000 baud.
- 8 bits per character.
- 1 stop bit.
- No parity.
- Software handshake – none.
- Xon/Xoff and ENQ/ACK not supported by the spectrum analyzer.
The manual enumerates the handshaking lines:
- Request to send (RTS) – Output signal indicates that the spectrum analyzer is ready to communicate. This line is true at power-up and stays true while power is on.
- Clear to send (CTS) – Input signal indicates that the external controller is ready to receive data.
- Data terminal ready (DTR) – Output signal from the spectrum analyzer. When the input buffer is full, this line goes false.
- Data set ready (DSR) – Is not available.
- Data carrier detect (DCD) – Input to the spectrum analyzer. If DCD is true, the spectrum analyzer will receive data from the controller. If false, no data will be input. The data will be ignored.
Furthermore, it is written:
The spectrum analyzer checks its CTS input before transmitting data to the computer. If the CTS line is false, the spectrum analyzer will not transmit data. The spectrum analyzer transmits data when the CTS line is true.
The spectrum analyzer sets the DTR line (PC CTS) false when its input buffer is full.
They offer several wiring diagrams, none of which correspond to the hardware on my bench, but swapping the “Personal Computer” and “Analyzer” headings on this diagram seems close to reality:
HP 8591 – RS232 DB25 to DE9 wiring diagram
On the other end of the cable, the PS410 does “hardware flow control using RTS/CTS”. They also offer a diagram:
Sena PS410 – RS232 wiring diagram
So I rewired the cable thusly:
HP 8591 vs Sena PS410 – RS232 cable diagram
Pin 1 on the 8591 interface connects to both frame ground and signal ground and, back when I first made this cable, many years ago, I had wired it to the shield of the cable and thence to the DE9 shell. Alas, the PS410 took offense; for reasons I don’t understand, a shell-to-ground connection ignites a ferrite bead on the PS410’s PCB.
With the rewired cable in hand, the PS410 serial port setup looks like this:
Port 2 – 8591 serial config
The PS410 apparently wiggles its RTS output after every byte it receives, because the CTS input at the 8591 turns into a blur during screen captures. This seems unaffected by the Inter character time-out setting and doesn’t (seem to) produce any problems, so it’s like that and that’s the way it is.
Using 9600 b/s isn’t as slow as you might think. The HP manual notes:
Some of the programs in this manual use 1200 baud for proper operation. If your system uses the RS-232 handshake lines, you can use 9600 baud for all of the programs.
I tried 19200 b/s and got mysterious errors that resemble overruns, which suggests the 8591 ignores the PS410’s flickering RTS output. The screen dumps require only a few seconds, so it’s not a big deal, although timing issues have a way of resurfacing at the most inopportune, uh, times.
Kermit knows how to handle network sockets and suchlike, so aiming it at the spectrum analyzer is a one-liner:
set host 192.168.1.40 7002 /raw-socket set modem none
The /raw-socket disables Kermit’s default Telnet interface, preventing it from squirting IAC + BRK characters when closing the session; I think that’s what happens, but I don’t use Telnet enough to know better. As you might expect, the 8591 deals poorly with characters outside its lexicon.
It’s not obvious set modem none does anything in this context, but it seems reasonable.
Then the rest of the script Just Works:
FM 104.7 MHz peak hold
Which is the peak-hold spectrum of a local FM station, as received through an amateur radio HT rubber duck antenna.
The Kermit source code as a GitHub Gist:
Sena PS410 Serial Server: Configuration
Posted by Ed in Electronics Workbench, PC Tweakage, Software on 2018-03-23
Although I cannot explain why those ferrite beads lit up, it seems connecting the DE-9 shell to the serial device ground is an Extremely Bad Idea. I removed that wire from the HP 8591 spectrum analyzer cable and everything seems to work, so I’ll declare victory:
Sena PS410 Serial Server – in action
Not shown: the tangle of cables tucked behind that tidy box. You can plug a serial terminal into the DE-9 connector, but it’s much easier to use the PS410’s web interface.
It needs a static IP address to make it findable, although I also told the router to force the same address should it start up in DHCP mode:
IP Configuration
Yeah, Google DNS, if all else fails.
The serial port overview:
Serial port overview
I’ll go into more detail in a while about individual device setups and the scripts slurping screen shots out of them, but giving each one a useful name is a Good Idea, even though it doesn’t appear anywhere else. I changed the default Inactivity Timeout for each port from the default 100 seconds to zero, thereby preventing the PS410 from closing the connection due to inactivity:
Serial Port 2 – host params
The DTR and DSR defaults work out well; the other choices solve problems I don’t have. Indeed, the PS410 has a myriad configuration options best left in their Disabled state.
The serial parameters for each port need tweaking to suit the hardware gadget on the other end of the cable:
Serial Port 2 – serial params
Flow Control applies between the PS410 and the gadget. You can choose:
- Disabled
- XON/XOFF – in-band characters
- RTS/CTS – RS-232 hardware signals
Somewhat to my surprise, It Just Worked despite my blundering.
Streaming Radio Player: Timing Tweaks
Posted by Ed in PC Tweakage, Software on 2018-03-22
Slowing the SPI clock and updating the drivers having had no noticeable effect on the OLED display corruption, I once again pondered the SH1106 controller timing specs.
The chip reset seems remarkably slow, even at maximum VCC:
SH1106 – Reset Timing Specs
I think the relevant code is in the luma.core driver’s serial.py file. On the RPi, it resides in /usr/local/lib/python2.7/dist-packages/luma/core/interface/.
As far as I can tell, the bitbang class handles all the setup and teardown around the actual data transfers, but it’s not clear (to me, anyway) how it interacts with the underlying hardware SPI machinery.
So, let’s add some sleepiness to the Reset code:
if self._RST is not None:
self._gpio.output(self._RST, self._gpio.LOW) # Reset device
time.sleep(1.0e-3)
self._gpio.output(self._RST, self._gpio.HIGH) # Keep RESET pulled high
time.sleep(1.0e-3)
A few milliseconds, rather than a few (hundred) microseconds, won’t make any perceptible difference.
Similarly, the Chip Select and Address (Command/Data) signals require more delay than might occur between successive Python statements:
SH1106 – SPI Address and Select Timing Specs
This should do the trick, again with excessive delay:
if self._DC:
self._gpio.output(self._DC, self._cmd_mode)
time.sleep(1.0e-3)
... snippage ...
if self._DC:
self._gpio.output(self._DC, self._data_mode)
time.sleep(1.0e-3)
... snippage ...
if self._CE:
gpio.output(self._CE, gpio.LOW) # Active low
time.sleep(1.0e-3)
... snippage ...
if self._CE:
gpio.output(self._CE, gpio.HIGH)
time.sleep(1.0e-3)
Although it shouldn’t be necessary, I blew away the pyc files to prevent future confusion over who’s doing what with which.
Once again, this will require several weeks to see whether the situation changes for the better.
Sena PS410 Serial Server: Burnin’ In
Posted by Ed in Electronics Workbench, Machine Shop, PC Tweakage on 2018-03-21
The USB serial adapters I use to capture HP54602 scope and HP8591 spectrum analyzer screenshots, as well as monitor the HP Z8501 GPS time standard, lack unique identifiers and appear as unpredictable device nodes.
After putting up with this for far too long, I dropped $15 on a Sena Technologies PS410 serial server:
Sena PS410 Serial Server – interior
It needed a new lithium coin cell, of course:
Sena PS410 Serial Server – as-received CR2032
The PCB and chip date codes suggest a 2009 build, so “98” might mean August 2009. Whether that’s the manufacturing date or the best used by date, ya never know.
The eBay deal didn’t include the power supply, so I hacked a coaxial jack on the back:
Sena PS410 Serial Server – hacked power jack
A 14 VDC IBM laptop brick from the pile suits the “9 to 36 V” range printed on the case.
Poking the “factory reset” switch did what you’d expect and the “console” serial port on the front worked fine. I plugged in the scope, the spectrum analyzer, and the GPS receiver, whereupon the bench took on the unmistakable aroma of electronic death:
Sena PS410 Serial Server – charred ferrite chip
Some probing suggests FB9 used to be a ferrite bead between serial port 2’s ground pin and the frame ground.
To compress an afternoon of tinkering into one sentence, there seems to be an occasional 35 VAC difference between the spectrum analyzer and the scope, but only when one or the other is plugged into the PS410. Everything is (now!) plugged into the same branch circuit and, in fact, the same outlet via many power strips, but the difference remains. A different power supply makes no difference, either.
I managed to burn out the ferrite bead on Port 1 with only the scope and the power supply plugged in, by connecting the scope’s ground lead to the shell of Port 2. That makes no sense: there is no voltage difference between the scope’s serial ground and its probe ground.
Something Is Not Right, but I’m baffled.
I have established that the server works fine, even with the charred beads, which is a Good Thing.
Streaming Radio Player: RPi and OLED Updates
Posted by Ed in Electronics Workbench, PC Tweakage, Software on 2018-02-28
Because the OLED driver came from the pip package manager, not the Raspberry Pi’s system-level apt package manager, it (or they, there’s plenty of code under the hood) don’t get updated whenever I do system maintenance. The doc says this should do the trick:
sudo -H pip install --upgrade luma.oled
However, it turns out the new version has a slightly longer list of pre-requisite packages, causing the update to go toes-up at a missing package:
Could not import setuptools which is required to install from a source distribution. Please install setuptools.
So update (or install, for the new ones) the missing pieces:
sudo apt-get install python-dev python-pip libfreetype6-dev libjpeg-dev build-essential
Doing so produced a backwards-compatibility error in my Python code:
... change ... from luma.core.serial import spi ... into ... from luma.core.interface.serial import spi
The motivation for all this fuffing and fawing came from watching some OLEDs wake up completely blank or become garbled in one way or another. Evidently, my slower-speed SPI tweak didn’t quite solve the problem, although it did reduce the frequency of failures. I have decided, as a matter of principle, to not embrace the garble.
Soooo, let’s see how shaking all the dice affects the situation.
It’s entirely possible the OLED controllers don’t quite meet their specs, of course, or have begun deteriorating for all the usual reasons.
Kinesis Freestyle2 Keyboard: Linux Fix
Posted by Ed in PC Tweakage, Software on 2018-02-16
Someone who found my original post about the Freestyle2’s dysfunctional media keys came up with a fix: https://github.com/whereswaldon/kfreestyle2d.
Kinesis Freestyle2 Media Keys
Some notes for the next time this comes up:
After doing sudo modprobe uinput, lsmod | grep uinp returns nothing at all (Xubuntu 16.04), but evtest seems perfectly happy:
sudo evtest /dev/input/event17
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x58f product 0x9410 version 0x0
Input device name: "KB800 Kinesis Freestyle"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 140 (KEY_CALC)
Properties:
Testing ... (interrupt to exit)
Event: time 1518199358.454619, type 1 (EV_KEY), code 113 (KEY_MUTE), value 1
Event: time 1518199358.454619, -------------- SYN_REPORT ------------
Event: time 1518199358.454638, type 1 (EV_KEY), code 113 (KEY_MUTE), value 0
Event: time 1518199358.454638, -------------- SYN_REPORT ------------
Event: time 1518199361.014681, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1518199361.014681, -------------- SYN_REPORT ------------
Event: time 1518199361.014699, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1518199361.014699, -------------- SYN_REPORT ------------
Event: time 1518199361.654701, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1518199361.654701, -------------- SYN_REPORT ------------
Event: time 1518199361.654721, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1518199361.654721, -------------- SYN_REPORT ------------
Event: time 1518199362.294715, type 1 (EV_KEY), code 140 (KEY_CALC), value 1
Event: time 1518199362.294715, -------------- SYN_REPORT ------------
Event: time 1518199362.294733, type 1 (EV_KEY), code 140 (KEY_CALC), value 0
Event: time 1518199362.294733, -------------- SYN_REPORT ------------
And the keys work without any special configuration on my part. Apparently they’re already built into XFCE, despite the sound keys not showing up in the Keyboard Shortcuts control panel where you assign programs to keys.
This is wonderful work!
I’ve never seen so many calculators before! Oops.
There should be some udev-rule-ish way to automagically figure out which /dev/hidraw? device to use and symlink to a suitable alias, so the program could use it without knowing the actual device. A casual search turns up:
With which I’d produce /dev/input/kinesis0 and kinesis1, then use:
/home/ed/bin/kinesis/kfreestyle2d /dev/input/kinesis1
If only the Kinesis Fn key was momentary, rather than a push-on / push-off toggle. Le sigh. I can cope.
-
You are currently browsing the archives for the PC Tweakage category.
Blowback